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ABSTRACT 

This document provides a basis for comparison of selected IBM Token-Ring LAN 
Gateway and Bridge communication products. Product inclusion was based on 
provision of connectivity for LAN attached devices to S/370 host based appli- 
cations. Product characteristics are examined relative to host connectivity, 
configuration, price, availability, manageability, performance considerations 
and other related network capabilities. Network scenarios are included and 
present situations, recommendations and alternatives. 

This document is intended for the direct use of IBM Marketing and Systems En- 
gineers (ie. for IBM Internal Use Only). However, the information contained 
in the document may be used as a consultative aid in developing a response to 
questions that may arise regarding the related products 
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I. INTRODUCTION 

This document describes selected IBM Token-Ring LAN Gateway and Bridge products. 
Only IBM products that might be reasonably dedicated to the gateway or bridging 
function are discussed in the main body of the document. Additionally, the 
comparison is focused on the connectivity of LAN attached devices to S/370 host 
bas ed app 1 icat ions . 

Note: The name Token-Ring will also appear in the abbreviated form T-R within 
the text, charts and diagrams in this document. 

For the purposes of this discussion a gateway is defined as a hardware and/or 
software product that provides connection of T-R LAN attached devices to a S/370 
host. In most cases the gateway access is via SNA networking facilities. There 
are valid exceptions such as the 3172 access to TCP/IP S/370 host based facil- 
ities. 

A bridge, on the other hand, is defined as a hardware and/or software product 
that provides connection of one T-R LAN to another. The bridging may be remote 
(ie. over communication links) or local (direct T-R to T-R ) connection. 
Token-Ring LAN facilities (remote or local) require channel attached gateways 
to access S/370 resources. 

The above definitions are specific to the discussions contained in this docu- 
ment. They may not be valid in the broader sense, especially relative to the 
changing communication environment. 

Each product section includes a discussion of product characteristics relative 
to the host connection, configurations, prices, availability, manageability, 
performance considerations and related networking capabilities. Where avail- 
able, specific performance scenarios are also included. 

IBM products that are primarily application processors yet also provide ancil- 
lary gateway functions (ie. the AS400, 9370 etc.) are discussed relative to 
that function. See Appendix A for that information. 

The products involved fall into two categories relative to host attachment. 
Some products perform their function via direct channel attachment to the S/370 
and others function as remote, link attached facilities. Those that function 
remotely still require the services of a channel attached facility in order to 
gain access to the S/370 channel. Some of the products require consideration 
in both categories because they function in both local (channel attached) and 
remote (link attached) environments. 

The product information was supplied by the responsible product development 
organizations. The scenarios were developed by Telecommunications Systems 
Support - Raleigh (TSS), based on common connectivity issues encountered through 
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workshops (etc.)- All information was integrated, edited and published by 
Telecommunications Systems Support - Raleigh. 
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II. HOW TO USE THIS DOCUMENT 
This document has two major divisions: 

Quick Reference Material 

■ Product Selection Scenarios 

■ A Summary (Netting It Out - 2 pages) 

■ Product Reference Charts (Appendix B - 2 pages) 
Detail Product Reference Material 

■ Product Section - Dedicated S/370 SNA Gateways and Bridges 

■ Appendix A - Other IBM Gateways 

This document uses a new approach for a "Raleigh Greenbook" . Is this type of 
product positioning coverage (ie. depth, content etc.) useful to you? Please 
help us determine whether or not you find it meets your needs by filling out 
the user comment form in the back of this document. 

This information is directed at two very different groups. First, those who 
have a good understanding of SNA and IBM communication products should find the 
detail information on performance and functional considerations helpful in 
supporting their analysis of available solutions. Second, those who have a 
limited understanding of certain aspects of communications and T-R connectivity 
should find the product selection scenarios quite helpful in getting started 
in the selection process. Then, after gaining familiarity with the scenarios 
those in the second group can refer back to the particular product section they 
feel best suits their situation and study the details of their product choice. 
Either group will find the Summary section and the Cross Reference Charts 
helpful as a "memory jogger" or as a starting point from which to launch into 
further examination and analysis. 

Performance information in this document is provided for general product com- 
parison purposes. The responsible support organizations in Austin, Dallas, 
Gaithersburg and Raliegh (SNAP/SHOT) continuously review/update performance 
information relative to their support function. The appropriate organization 
should be should be contacted for assistance in detail network design perform- 
ance analysis. 

In either case, it is important to understand and respond to the customer's 
product selection criteria. Product specific information such as function, 
performance and unit price are important influences in the gateway selection 
process. Meeting the customer's requirements by recommending IBM products 
matched to the task is key to customer satisfaction. 
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However, one element of the selection process is often overlooked. It is JUST 
AS IMPORTANT to consider "where the customer has come from", "where they are 
at this point" and "where they will be going". For instance: if the customer 
has never dealt with S/370 host based networks and has only been involved with 
departmental or establishment LANs, such things as bandwidth management and 
network management of long lines may be of little concern. The price and per- 
formance of the solution used to connect the separate LANs may be that custom- 
er's primary concern. 

On the other hand, if the customer has NetView installed on the host processors 
and has just completed a major training program in its use, the customer will 
logically consider network management a key factor in the decision. 

Likewise, a customer who has experience with installed TCP/IP based solutions 
will probably find the 3172 Interconnect Controller, 8209 LAN Bridge and Remote 
Bridges the preferable solution (The 3172 and 8209 are described in Appendix 
A). 

It is clearly as important to consider the customer's orientation and/or envi- 
ronment, as it is to understand product price, performance and function. Both 
are necessary to assist the customers selection of their BEST solution. 

Note: Throughout this document the term Token-Ring may refer to a single 
Token-Ring or a collective Network of bridged Token-Rings. 

The IBM Token-Ring Network and The IBM PC Network are both local area networks . 
In this document the IBM Token-Ring Network may be referenced as T-R, or 
Token-Ring. The term LAN may also be appended to such references and is to be 
read as "IBM Token-Ring Network, a local area network (ie. LAN) 
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III. PRODUCT SECTION 

This section presents information about each product. The objective is to 
present the essential information in adequate detail, yet be brief and concise 
enough to encourage use. 

This section includes the following IBM products: 

■ Personal Communications/3270 Gateway 

■ OS/2 EE Version 1.2 SNA Gateway 

■ Token-Ring Network Bridge Program V2.1 

■ 3174 Token-Ring LAN Gateway 

■ 3745 Communications Controller 

The following IBM products are also considered and are covered in Appendix A: 

■ 3172 Interconnect Controller 

■ 8209 LAN Bridge 

■ ES/9370 

■ AS/400 

■ 8232 LAN Channel Station 
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III. A. 

PERSONAL COMMUNICATIONS/3270 GATEWAY 

OVERVIEW 

The Personal Communications/3270 (PC/3270) is any PS/2 (or PC) using PC/3270 
to provide connectivity for its attached, client workstations to a S/370 host. 

The PC/3270 gateway is a replacement for the PC 3270 Emulation Program and is 
very similar in function to the OS/2 EE gateway. This section will discuss the 
differences between the PC/3270 gateway and the PC 3270 Emulation Program 
stressing significant capabilities of the PC/3270 gateway. 

The PC/3270 gateway is a convenient and efficient way to provide access to an 
IBM S/370 host for multiple PC users. It provides, among other things, support 
for: 

Downstream Token-Ring and PC Network LAN attachment 

Upstream SNA and Token-Ring attachment 

LU (session) pooling 

SNA (3270, HLLAPI, SRPI and APPC) applications 

Migration from PC 3270 Emulation Program 

Network management support 

This product replaces the PC 3270 Emulation Program Version 3.0 (EP V3) . EP 
V3 will be withdrawn effective 12/29/89 with service provided through July 31, 
1990 to allow customers time to migrate to the replacement product. Upgrades 
are available, both for single-units and additional licenses. Upgrades also 
apply to migration from PC 3270 Emulation Program Version 3, PC 3270 Emulation 
Program Entry Level Version 1.2 and 3270 Workstation Program Version 1.1. Up- 
grade considerations also apply to INPCS Version 1.1 and INPCS Entry Version 
1.1. 

Note: Personal Communications/3270 may also be referenced as PC/3270. This 
should not be confused with PC 3270 which references a predecessor product. 

Personal Communications/3270 provides enhanced gateway services for the PS/2 
and PC. These enhancements include: 

■ An IEEE 802.2 interface between the gateway and LAN workstations, allowing 
customers to mix and match LAN workstation programs to meet user require- 
ments ....''• 
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■ LAN workstations installed with the Token-Ring adapters may use: 

▲ Personal Communications/3270 

▲ OS/2 Extended Edition Version 1.1/1.2 

▲ PC 3270 Emulation Program Version 3.0 

▲ 3270 Workstation Program Version 1.1. 

a APPC/PC 

Note: The gateway may communicate to the S/370 host via Token-Ring, 
SDLC or SNA-DFT. 

■ LAN workstations installed with PC Network adapters may use: 

▲ Personal Communications/3270 

A PS/2 Extended Edition Version 1.1/1.2 

▲ 3270 Workstation Program Version 1.1. 

Note: The gateway may communicate to the S/370 host via SDLC or SNA-DFT. 

The maximum number of host sessions has been increased to 253 when this 
gateway is attached via either SDLC or Token-Ring. This is a significant 
enhancement over the prior 32 sessions supported by the PC 3270 Emulation 
Program Version 3.0. The maximum number of SNA DFT sessions remains at 5. 

■ Pre-allocated sessions, session pooling, or a combination thereof can be 
provided via the gateway. 

■ Gateway performance is improved relative to the PC 3270 Emulation Program 
Version 3.0 

The SNA sessions supported through the Personal Communications gateway may be 
a mixture of LU-1, 2, 3, or Dependent LU-6.2 (PU2.0) sessions. 
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MODEL NETWORK DIAGRAM 
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Figure 1. PC} 3270 Gateway Example 



CONFIGURATION AND PRICE EXAMPLE 

Token-Ring adapter 

SNA communication adapters 

PS/2 (1 Meg) 

DOS 3.3 

Personal Communications/3270 

Total Price 



895 
305 
3,525 
120 
459 

5,304 



** PS/2 Model 50Z with monochrome display. 

NOTE : The prices indicated are list prices. Volume discounting is available. 

Any PS/2 or PC with a fixed disk may act as the gateway provided it has suffi- 
cient memory and the appropriate adapters (for both the upstream host connection 
and the downstream LAN connection) . The cost of gateway may range from less 
than $5304 for a PC-XT with an SDLC and PC Network adapter to a PS/2 5380, Model 
311 with a Token-Ring adapter for $12890. 
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ATTACHMENT/CONNECTIVITY 

PC/3270 GATEWAYS PROVIDE THE FOLLOWING UPSTREAM CONNECTIVITY: 

■ Communication /Link -lev el access is via: 

SDLC links at up to 19.2Kbps 

■ The Token-Ring at 4Mbps or 16Mbps 

■ DFT connection via the 3174 

■ Application access is via: 

3270 emulation sessions (SNA PU2.0) 

Dependent LU6.2 (SNA PU2.0) 

SRPI/HLLAPI API's 

Note: The workstation application is responsible for providing its end of 
the appropriate LU protocol (ie. 3270 emulation, APPC, etc.) 

■ The gateway supports up to 253 LU sessions via the Token-Ring or SDLC con- 
nections and/or up to 5 LU sessions via the 3174 DFT connection. (Refer 
to the LU Pooling discussion for efficient LU assignment techniques.) 

PC/3270 GATEWAYS PROVIDE THE FOLLOWING DOWNSTREAM CONNECTIVITY: 

■ The client workstations may reside on: 

1 or 2 Token-Ring LANs 
A PC Network LAN 

■ Up to 256 workstations may be configured per gateway 

When the gateway is connected to a System/370 host via SDLC or Token-Ring IEEE 
802.2, the gateway appears to the host as a single SNA PU Type 2.0 node with 
up to 253 LUs attached. The number of individual workstations supported si- 
multaneously through the gateway is limited by the amount of memory available 
on the network adapter. Refer to the IBM Local Area Network Technical Reference 
Manual, SC30-3383 to calculate the number of individual workstations supported 
by each Token-Ring adapter. 

The gateway appears to its attached workstations as an SNA Primary communi- 
cations device. It emulates the PU and LU activation and deactivation functions 
necessary to establish and maintain SSCP-PU and SSCP-LU sessions with the 
downstream workstations. Once the SSCP-PU and SSCP-LU sessions have been es- 
tablished with the workstation, all data flowing on the SSCP-LU and LU-LU ses- 
sions is passed through the gateway transparently. The gateway maintains the 
SSCP-LU sessions with the host when the LU is not allocated to a workstation. 

When connected SNA DFT, the gateway appears as a DFT device with up to five host 
sessions. In this configuration the control unit manages the SSCP-PU session 
with the host and maps the SSCP-LU session control commands (ACTLU and DACTLU) 
to control unit status commands in the adapter buffer. The gateway maintains 
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the SSCP-LU sessions with the host when the LU is not allocated to a work- 
station. 

PERFORMANCE/CAPACITY/THROUGHPUT 

Personal Communications/3270 uses an improved method of establishing session 
communication between the gateway and LAN workstation compared to PC 3270 Emu- 
lation Program Version 3. This reduces start-up time for workstations attached 
via large networks and reduces gateway congestion. When the gateway is acti- 
vated it establishes communications with the S/370 host for all LUs and is ready 
to provide the appropriate LU session(s) when polled by the LAN workstation. 

Due to the wide range of variations in gateway and LAN workstation configura- 
tions, providing exhaustive performance data is not practical. However, limited 
tests were performed comparing LAN workstation access to a S/370 host. The 
gateways were configured similarly except for the specific gateway program (PC 
3270 Emulation Program Version 3 or the Personal Communications/3270 Gateway). 
Host access performance was measured using the same Token-Ring adapter and the 
same PIU size of 265 bytes. The performance results for file transfer of a 100K 
file showed a 10 to 25% advantage using the Personal Communications/3270 Gate- 
way. When the PIU size was increased to 2K (not possible using the PC 3270 
Emulation Program Version 3), the performance advantage exceeded 25%. 

As shown by these tests, improved performance can be expected using Personal 
Communications/3270 gateway. Specific performance improvements will vary de- 
pending upon gateway configuration, host connection, LAN adapter connection and 
LAN workstations' configurations. It is highly recommended that LAN/Gateway 
administrators perform appropriate performance measurements in their specific 
LAN environments . 

USEABILITY AND MANAGEABILITY 

Profiles and Session Pooling 

A default workstation profile is provided to significantly reduce the effort 
necessary to configure a gateway for multiple users with similar or identical 
host requirements. The gateway administrator needs only to configure the de- 
fault profile for the gateway to allocate host sessions to all workstations to 
which the default profile applies. Sessions supported through the gateway may 
be pooled by the default profile or specific profiles. The gateway also allows 
pre-allocated sessions to be defined to a specific workstation by specifying a 
unique workstation PUid. The specific workstation profile may be further 
identified by providing the optional workstation adapter address. 

Gateway Status 

A Gateway Status Utility provides a link log table to assist the gateway ad- 
ministrator. This utility displays a time stamped link status history to assist 
in problem determination. Additionally, any new link status messages received 
while the display is being viewed will also be displayed. The gateway status 
utility also provides information specific to all sessions allocated to the 
gateway. 
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Information is formatted to contain all pertinent data for each workstation. 
Information consists of the: 

PUid 

PU state and network adapter address 

Workstation designation address 

Host destination address 

Current state for each LU session table entry 

Network Management 

■ The IBM PC 3270 Emulation LAN Management Program Version 1.0 used with the 
IBM PC 3270 Emulation Program Version 3.0 gateway provides monitoring for 
small, remote LANs. It provides alerts to NetView for both Personal 
Communications/3270 (via NETBIOS) and. PC 3270 workstations through PC 3270 
EP V3.0. gateway. 

The capability for IBM PC 3270 Emulation LAN Management Program Version 1.0 
to be installed in a Personal Communications/3270 gateway system is avail- 
able February 16, 1990. This capability will be provided upon request to 
licensed users of Personal Communications/3270 via a Corrective Service 
Diskette available through the appropriate support channel of the licensed 
user. Existing workstations on the LAN must be reconfigured to communicate 
via the IEEE 802.2 interface provided in the IBM LAN Support Program Version 
1.1. 

■ For Personal Communications/3270 workstations communicating via the IEEE 
802.2 interface to a 3174 or 37XX Communications Controller gateway to an 
IBM host and residing on the network with IBM OS/2 Extended Edition Version 
1.1, network management for the Personal Communications/ 3270 workstations 
can be provided by the IBM LAN Manager Entry Version 1.0 or LAN Manager 
Version 1.0 or 2.0. 

UNIQUE/EXCLUSIVE CAPABILITIES 

The gateway PS/2 (or PC) need not be dedicated to the gateway support function. 
It may also function in other capacities supported by Personal 
Communications/ 3270 facilities. Appropriate planning /scheduling must be done 
to prevent impacting gateway performance and/or availability. 

Non-dedicated usage may require use of a DOS address space management program. 
There are a number of such products currently available from OEM software 
sources. They use disk space, expanded memory and or extended memory to swap 
one of a number of inactive DOS partitions to the single active 640K partition. 
The previously active partition becomes inactive until it is swapped in again. 

SPECIAL CONSIDERATIONS 

In certain situations the use of PC/3270 Gateway can be used with other 
gateway /bridge products to aid resource utilization and performance. This is 
done by reducing the number of workstation PU's that must be defined to and 
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polled by the NCP. The/PC 3270 gateway concentrates multiple workstations into 
1 upstream PU before they are processed upstream (directly or via other 
gateways/bridges). 
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III.B. 

OS/2 EE VERSION 1.2 SNA GATEWAY 

OVERVIEW 

The OS/2 EE Version 1.2 SNA GATEWAY (EE gateway) is any PS/2 (or PC) using OS/2 
EE VI. 2, to provide connectivity for its attached, client workstations to a 
S/370 host. 

The OS/2 EE VI. 2 gateway is very similar in function to the PC/3270 gateway. 
Therefore; this section will focus on extended capabilities and other signif- 
icant differences. 

The OS/2 EE gateway is a convenient and efficient way to provide access to an 
IBM S/370 host for multiple PC users. It provides, among other things, support 
for: 

A variety of downstream link/LAN types 

A variety of upstream link types 

LU (session) pooling 

SNA (3270, HLLAPI, SRPI & APPC) applications 

Migration and/or coexistence with DOS-based emulators 

Network management support 

Non-dedicated usage ( ie. Multi- tasking with other OS/2 EE facilities such 
as LAN Manager, File Services, etc.) 

The gateway facilities are an integral part of the OS/2 EE multi-tasking oper- 
ating system which is designed as the platform for current and future distrib- 
uted applications. 

The OS/2 EE gateway is the appropriate choice for customers migrating from DOS 
to OS/2. 

The OS/2 EE gateway supports larger T-R environments than DOS gateways due to 
the inherent architectural advantages of the OS/2 operating system: 

■ Large memory/address space facilities 

■ Multi-tasking operating system 

■ Micro-channel/Bus-mastering capabilities 
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MODEL NETWORK DIAGRAM(S) 
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Figure 2. OS} 2 EE Gateway Example 



Up to 19.2Kbps via 
multi-point SDLC or 
64Kbps X.25 (pt-pt) 



CONFIGURATION AND PRICE EXAMPLE 

Token-Ring adapter 

SNA communication adapters 

PS/2 (7 Meg) 

OS/2 EE 

Total Price 



895 

305 

7,350 

830 

9,380 



** PS/2 Model 50Z with monochrome display. 

NOTE : The prices indicated are list prices. Volume discounting is available. 

Any EE-supported PC may act as the gateway provided it has sufficient capacity 
and the appropriate attachment cards (for both the LAN connection and the host 
link). Thus it may range from a PC AT to a PS/2 model 80. The resulting price 
would range from around $8000 to $18000 at non-discounted prices. Remember 
that these PCs could provide services other than just gateway support . 
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ATTACHMENT/CONNECTIVITY 

OS/2 EE GATEWAYS PROVIDE THE FOLLOWING S/370 UPSTREAM 
CONNECTIVITY: 

■ Communication/Link- level access is via 

SDLC links at up to 19.2Kbps 

■ X.25 links at up to 64Kbps 

■ The Token-Ring at up to 16Mbps 

■ Application access is via: 

3270 emulation sessions (SNA PU2.0) 
Dependent LU6.2 sessions (SNA PU2.0) 
SRPI/HLLAPI API's 

■ The gateway supports up to 254 LU sessions (Refer to LU Pooling for effi- 
cient LU assignment techniques.) 

OS/2 EE GATEWAYS PROVIDE THE FOLLOWING DOWNSTREAM CONNECTIVITY: 

■ The client workstations may reside on: 

A Token-Ring LAN 

An Ethernet LAN (as documented in the Digital Intel Xerox (DIX) Version 
2.0 specification) 

A PC Network LAN 

An IEEE 802.3 LAN 

Workstations may also be attached to the EE VI. 2 gateway via: 

An X.25 Packet Switched Data Network (PSDN) 

An SDLC switched line 

■ Up to 256 workstations may be configured per gateway (64 active at one 
time) . 

When the gateway is connected to a System/370 host via SDLC or Token-Ring IEEE 
802.2, the gateway appears to the host as a single SNA PU Type 2.0 node with 
up to 254 LUs attached. The number of individual workstations supported si- 
multaneously through the gateway is limited by the amount of memory available 
on the network adapter. Refer to the IBM Local Area Network Technical Reference 
Manual, SC30-3383 to calculate the number of individual workstations supported 
by each Token-Ring adapter. 

The gateway appears to its attached workstations as an SNA Primary communi- 
cations device. It emulates the PU and LU activation and deactivation functions 
necessary to establish and maintain SSCP-PU and SSCP-LU sessions with the 
downstream workstations. Once the SSCP-PU and SSCP-LU sessions have been es- 
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tablished with the workstation, all data flowing on the SSCP-LU and LU-LU ses- 
sions is passed through the gateway transparently. The gateway maintains the 
SSCP-LU sessions with the host when the LU is not allocated to a workstation. 

PERFORMANCE/CAPACITY/THROUGHPUT 

Performance numbers were not available for inclusion in this section of the OS/2 
EE gateway discussion. In addition, the number of potentially applicable con- 
figurations that could be developed is rather unwieldy. Therefore rather than 
address the issue by examining detail configurations, the following "factors 
to consider" are provided as a means of establishing an acceptable configura- 
tion: 

■ The number of workstations requiring support 

■ The application population and concurrent support requirements 

■ Application usage profiles (ie. light to heavy query/update transaction 
activity and/or batch file transfer) 

■ Response time requirements 

Telecommunications Systems Support - Dallas, LAN Support, has run some prelim- 
inary performance tests and is in the process of making that information 
available on-line. 

USABILITY AND MANAGEABILITY 

Profiles and Session Pooling 

A default workstation profile is provided to significantly reduce the effort 
necessary to configure a gateway for multiple users with similar or identical 
host requirements. The gateway administrator needs only to configure the de- 
fault profile for the gateway to allocate host sessions to all workstations to 
which the default profile applies. Sessions supported through the gateway may 
be pooled by the default profile or specific profiles. The gateway also allows 
pre-allocated sessions to be defined to a specific workstation by specifying a 
unique workstation PUid. The specific workstation profile may be further 
identified by providing the optional workstation adapter address. 

The LU (or session) pooling support is helpful in two ways: 

■ It is often the case that only a subset of users require simultaneous use 
of LU sessions. A planned LU pool of reduced size can be allocated on a 
first come first served basis. This reduces the total number of LUs re- 
quired in the network and can free up those resources for other uses. This 
can result in faster re-starts and improved response. However, specific 
sessions can be still be dedicated. This way certain users can always ob- 
tain access by avoiding any LU pool contention. 

■ Second, it allows more than 64 workstations to be supported by putting some 
or all of the available LUs into the pool and allocating them across the 
user set as individual users request access to the host. 
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Inactive sessions can be terminated after a user-defined interval of time. This 
returns inactive resources to available status. 

Gateway Status 

A Gateway Status Utility provides a link log table to assist the gateway ad- 
ministrator. This utility displays a time stamped link status history to assist 
in problem determination. Additionally, any new link status messages received 
while the display is being viewed will also be displayed. The gateway status 
utility also provides information specific to all sessions allocated to the 
gateway. 

Information is formatted to contain all pertinent data for each workstation. 
Information consists of the: 

PUid 

PU state and network adapter address 

Workstation designation address 

Host destination address 

Current state for each LU session table entry 

Network Management 

Network management is supported by forwarding alerts from LAN Manager or the 
workstations to the host for monitoring by NetView. In the reverse; 
requests/commands from the NetView are passed to the workstations or LAN Man- 
ager, which can then respond accordingly. 

From a migration/coexistence viewpoint, The EE gateway may support workstations 
using: 

OS/2 EE itself (both VI. 1 or 1.2) 

Personal Communications/3270 (PC/3270) 

PC 3270 Emulation Program V3.0 

3270 Workstation Program VI. 1 

APPC/PC VI. 11 on the Token-Ring LAN 

The PC 3270 Emulation Program Version 3 is supported on Token-Ring adapters only 
via the IEEE 802.2 interface. The PC 3270 Emulation workstations must be con- 
figured for a Token-Ring connection. 

UNIQUE/EXCLUSIVE CAPABILITIES 

The multi-tasking facilities of OS/2 EE provide the capability to efficiently 
run gateway facilities and other tasks (ie LAN Manager) at the same time. This 
enhances Non-dedicated operations by more efficiently servicing other facili- 
ties running on the workstation (as opposed to facilities that only become ac- 
tive after they are called up by a "hot key"). Care should be taken to ensure 
that non-dedicated use does not impact performance and/or availability. 
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SPECIAL CONSIDERATIONS 

In certain situations the use of the OS/2 EE Gateway can be used with other 
gateway/bridge products to aid resource utilization and performance. This is 
done by reducing the number of workstation PU's that must be defined to and 
polled by the NCP. The OS/2 EE gateway can concentrates multiple workstations 
into 1 upstream PU before they are processed upstream (directly or via other 
gateways/bridges). 
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III.C. 

IBM TOKEN-RING NETWORK BRIDGE PROGRAM V2.1 (REMOTE BRIDGE) 

OVERVIEW 

The basic premise behind Local Area Networks is the sharing of network re- 
sources. The proliferation of Token-Ring Networks across enterprises has re- 
sulted in the requirement to extend this sharing of resources beyond the "local 
area" to geographically separate locations. The IBM Token-Ring Network Bridge 
Program Version 2.1 is intended to address this requirement. By providing pro- 
tocol independent connectivity between rings the bridge program will allow not 
only workstation to host communication, but peer-to-peer communication between 
workstations on the LAN as well. 

This discussion is focused on the Remote Bridge aspect of the program for the 
purpose of connecting remote T-R LAN attached workstations to a S/370 host. 
This configuration also requires a S/370 channel attached gateway to complete 
the process. 

The IBM Token-Ring Network Bridge Program Version 2.1 connects two rings of a 
4 Mbps and/or 16 Mbps Token-Ring Network into a single logical network. The 
bridge program can be configured to connect local rings or geographically sep- 
arate remote rings. When configured as a remote bridge, information is trans- 
ferred between rings over a dedicated communications line. Line operation is 
full duplex at speeds from 9.6 Kbps to 1.344 Mbps. 

FUNCTIONAL HIGHLIGHTS OF THE BRIDGE ARE: 

■ Provide protocol independent communication across the bridge for applica- 
tions written to the IEEE 802.2 Logical Link Control Interface using source 
routing 

■ Display ring status and fault domain details 

■ Maintain and display performance statistics 

■ Provide network management capability 

The bridge program also provides the capability of filtering frames forwarded 
by the bridge. A programming interface allows one or more filters to determine 
whether frames are allowed to pass through the bridge. Filters can be used for 
security and access control or, in the remote bridge environment, to help re- 
strict unnecessary traffic flow across the communications line. The following 
filters are provided with the bridge program: 
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■ Link limiting filter - limits the number of unique source and destination 
address pairs allowed to establish links through the bridge 

■ NETBIOS filter - restricts the proliferation of NETBIOS frames throughout 
the network 

■ Address filter - discards all frames containing source and destination ad- 
dresses within a specified range 

A sample filtering program will also be provided as a guideline to assist the 
user in writing a customized filter. As many as 10 filter programs may be used 
with each half of the bridge. 

A key feature of the bridge program is the network management capability. The 
bridge communicates with the IBM LAN Manager Version 2.0 to provide network 
management for the multi-ring environment. This allows centralized network 
monitoring and control via the LAN Manager (including error and failure de- 
tection and problem isolation). 

A major benefit of the bridge program is the capability of providing a protocol 
independent connection between rings . Because the bridge operates at the MAC 
level, it is not tied to the higher- level protocols. Consequently, the bridge 
can support multiple protocols simultaneously. A direct result is the reduced 
impact of network re- configuration. Since workstation definition is not re- 
quired in the bridge program, move and changes within the Logical LAN network 
have no impact on the bridge. 

Use of the bridge can enhance the availability of the network. The installation 
of parallel bridges in a LAN network provides an automatic backup system, in 
addition to dynamic load balancing. Bridging also provides alternative backup 
paths for traditional SNA network configurations. 

By bridging local and remote LANs into a Logical LAN Network; workstations, 
peripherals, and host computers can be linked together throughout an organiza- 
tion. This enables sharing of data, network resources, processing power and 
applications. In summary, the IBM Token-Ring Network Bridge Program Version 
2.1 provides a low cost solution for expanding Token-Ring connectivity re- 
quirements . 
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Figure 3. T— R Remote Bridge Example 



3174s or 3745s 



-AS400, 9370 (etc. ) 



9.6Kbps to 1.344Mbps 
PT-PT dedicated line 



-AS400, 9370 (etc.) 



CONFIGURATION AND PRICE EXAMPLE 

Two -Token -Ring adapters $ 1,790 

Two- communication adapters 2,760 

Two-PS/2's 7,050 
Two-IBM Token-Ring Network bridge program Version 2.1 3,190 

Two-DOS 3.3 240 

Two-Realtime Interface Co-Processor DOS Support 160 



Total Price 



$15,190 



* IBM X.25 Interface Co-Processor/2 with cable option V.35 required for 1.344 
Mbps 

** PS/2 Model 50Z with monochrome display. 

NOTE : The prices indicated are list prices. Volume discounting is available. 
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ATTACHMENT/CONNECTIVITY 

The remote bridge uses either the Realtime Interface Co-Processor or the X.25 
Interface Co-Processor/2 adapter for communicating across the line. The 
interfaces/speeds supported by each adapter are shown in the following chart. 



IBM Realtime Interface IBM X.25 Interface 
Interface Co-Processor Co-Processor/2 



RS-232C/V.24 9.6 - 19.2 Kbps 9.6 - 19.2 Kbps x 

V.35 9.6-64 Kbps 9.6 - 1.344 Mbps x 

X.21 bis/V.24 9.6 - 19.2 Kbps x 

X.21 bis/V.35 9.6 - 1.344 Mbps x 

X.21 (leased) 9.6-64 Kbps 

(x) The X.21 bis/V.24 electrical characteristics are compatible 
with EIA RS-232C. The X.21 bis/V.35 interface is equivalent 
to the CCITT V.35 interface. 

Figure 4. T— R Bridge Line Interface Chart 



The remote bridge supports applications written to the IEEE 802.2 interface 
using source routing. Applications can use connectionless or connection- 
oriented services. Typical LAN application protocols are NETBIOS, LU2, LU 6.2 
and TCP/IP. 

At slower line speeds applications using connection-oriented services may need 
to adjust certain parameters to work successfully across the remote bridge. 
Because of the limited (low) capacity of the communications line the following 
values may need to be adjusted: 

■ Maximum frame size 

■ Acknowledgement timer value (Tl timer) 

■ Retry count (N2) 

■ Number of outstanding frames allowed (Max out) 

Applications not allowing these adjustments may not perform well at the slower 
line speeds. In most cases, such problems will only arise when multiple ses- 
sions are active. 

Cascading of remote bridges IS NOT RESTRICTED, however the timing requirements 
of the logical link protocol and the application itself must be considered when 
implementing this configuration. Obviously, communication line speed is a 
critical factor in determining whether applications will work across cascaded 
remote bridges. It is the customer's responsibility to determine whether spe- 
cific applications will work in cascaded configurations. 

The remote bridge provides a MAC (Media Access Control) level connection between 
remote rings. MAC level connections are sessionXess. They do not provide 
"break" points for LLC, or affect the session pacing and flow control in use 
for the sessions that are flowing through the bridge. At the higher line speeds 
this is not likely to be a problem. However, at the slower speeds bridge con- 
gestion can occur and sessions could be dropped if NCP time-out thresholds are 
not set accordingly. In situations where sustained traffic bursts exceeds 
buffer/ line capacity, the following measures can be taken to alleviate problems: 
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■ Increase the line speed 

■ Install parallel bridges 

■ Use filters 

■ Set the NCP time-out threshold for a longer duration 

The only limits on the number of workstations or sessions supported by the re- 
mote bridge are performance and the number of LLC link connections . For a given 
line speed, the load becomes a function of the: 

Number of logical links 

Load on each link 

Flow control in effect on each link 

line speed in use. 

Length of the line itself 

Some of the key variables in determining the concurrent link capacity of the 
remote bridge in a specific environment are: 

■ Link protocol parameters (Tl timer, N2, Max out) 

■ Application parameters (timers, max frame size) 

■ NCP timeout parameters 

■ Remote bridge parameters 

■ Communication adapter transmit buffer size 

■ Max frame size supported 

■ Network traffic (amount of traffic across the link, broadcast traffic) 

■ System configuration (LAN to host, LAN to LAN) 

■ Network topology (single, multiple and parallel bridges) 

If the customer requires high speed (Tl) at a low product cost and does not 
require optimum intermediate link pacing/flow control and LPDA, then the remote 
bridge can provide the answer. For low speed connectivity requirements careful 
consideration needs to be given to the variables previously identified. 

Note: The remote-bridge has been successfully tested across both satellite and 
micro-wave communication links. Please note that the factors that impact 
interactive traffic via satellite (when using other products) also effect 
bridged Token-Rings. Propagation delay is the major consideration. Also, 
multiple hops and/or cascading can have a severe impact on reasonable perform- 
ance expectations. Please read the following section for assistance in under- 
standing the factors involved. 
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PERFORMANCE/CAPACITY/THROUGHPUT 

This sub-section contains performance information that is designed to provide 
information to support centers and branch offices concerning the use of the IBM 
Token-ring Bridge Network Program 2.1. The information is NOT intended for 
direct use by the customer. Rather, it is intended to provide initial guidance 
in product selection. This information is not a substitute for detail analysis 
of the customers specific networking requirements. 

In general, the remote-bridge is a device that interconnects two local area 
networks (LANs) separated by a distance of up to several thousand kilometers. 
The principle advantages of the remote-bridge is that it provides a cost ef- 
fective interconnection to remote services while maintaining a homogeneous LAN 
appearance; i.e., only LAN protocols are required to communicate over the 
remote-bridge. There are also potential advantage that accrue relative to 
high-speed, high -bandwidth transmission capabilities. 

USING KEY APPLICATIONS ACROSS THE REMOTE-BRIDGE 

This section describes testing that was conducted using the remote-bridge with 
some key IBM software applications. These applications are: 

Workstation Program 1.12 (WSP 1.12) 

3270 Emulation Program 3.04 (EP 3.04) 

Personal Communication/3270 (PC/3270) 

PC LAN Program 1.3 (PCLP 1.3) 

Remote Program Load (RPL) feature packaged with PCLP. 

WSP 1.12, EP 3.04, and PC/3270 tests were conducted using PS/2 Mod 50 's as the 
remote-bridge computers and PS/2 Mod 30 's for workstations. Tests using PCLP 
1.3 used a PS/2 Mod 70 for the server and PC XTs for re-directors; the remote 
bridge computers were PS/2 Mod 50Z's. The RPL tests were conducted using a PS/2 
Mod 70 and a PS/2 Mod 30 for loaders and PC XTs for requestors. An IBM 4341 was 
used for all tests requiring host a connection. 

The performance measurements used for these applications operating over a remote 
bridge were: 

■ Tables 1 and 2 

■ Optimum number of supported stations 

■ Maximum number of supported stations 

Note: Supported stations = workstations, re-directors, or requestors 

■ Tables 3 and 4 (Corresponding to tables 1 and 2) 

■ Average response times (for the Optimum number of stations) 

■ Average response times (for the Maximum number of stations) 

Following are brief descriptions of how each application was used in the 
remote-bridge tests. 
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Workstation Program 1.12 (to a 3174 local gateway) 

WSP 1.12 was used in two modes; to connect workstations executing NPT (Non- 
Programmable Terminal) traffic with a host via a remote-bridge, and to connect 
workstations executing file transfers from a host via a remote-bridge. In the 
NPT mode, each workstation was executing the A- 1200 (standardized test profile) 
workload at either 2.3 or 6.7 transactions per minute. For the file transfer 
mode, each workstation was executing a transfer of either a 40KB or 100KB file 
using a host as a file server. 

3270 Emulation Program 3.04 (to a 3174 local gateway) 

This application was used to connect NPT sessions across a remote-bridge. A 
varying number of workstations were attached to a remote T-R via a remote-bridge 
which was in turn connected to a host via a local T-R. Each workstation was in 
session with the host executing the A- 1200 NPT workload at 2.3 or 6.7 trans- 
actions per minute. 

Personal Communication/3270 (to a 3174 local gateway) 

PC/3270 was used to connect NPT sessions across a remote-bridge. A varying 
number of workstations were attached to 3174s, attached in turn to a remote T-R. 
That T-R was remote-bridged to the S/370 via local 3174 f s T-R. The workstations 
executed the A- 1200 NPT workload at 2.3 or 6.7 transactions per minute. 

PC LAN Program 1.3 

The test configuration that used PCLP 1.3 consisted of "server to re-director" 
file transfers across the remote-bridge. A varying number or re-directors exe- 
cuted a download of either 40KB or 100KB file from a PS/2 Mod 70 server. 

Application Test Results Summary 

The tables to follow summarize the results of the tests described above. The 
">" and "<" next to some of the table entries denote that the table entry is 
marginally greater than or less than the indicated value. The "*" next to some 
table entries denotes that the entry value was estimated via analytical methods . 
Default values were used for the attached products. 

Table 1.0 summarizes applications tested under NPT workloads. For example, at 
a TP line speed of 9.6KB/s, WSP 1.12 will support 12 workstations at an NPT rate 
of 2.3 transactions per minute, and greater than 4 workstations at 6.7 trans- 
actions per minute. 
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Figure 5. NPT Application Tests Results Summary: Attached Stations 
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Table 2.0 has a similar layout as that in Table 1.0 except that the focus is 
on file transfer performance. Therefore, the file sizes for each application 
is specified. For example, the maximum number of re-directors, each requesting 
a 100KB file download, that can be supported using PCLP 1.3 over a remote-bridge 
(at 1.344Mbps line speed) is greater than 16. 
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Figure 6. File Transfer Application Tests Summary: Attached Stations 
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For Table 3.0, the entries correspond to the average response times experienced 
by the attached stations shown in Table 1.0. For example, for the same entry 
mentioned in Table 1, each station will have an average response time of 2.6 
seconds at a transaction rate of 2.3 per minute and greater than 2.3 seconds 
at 6.7 transactions per minute. 
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Figure 7. NPT Application Tests Results Summary: Response Time(s) 
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Table 4.0 shows the corresponding average response time associated with the each 
station for the file transfer operation shown in Table 2.0. 
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Figure 8. File Transfer Application Tests Summary: Response Time(s) 



Summary of Other Tests 

For line speeds of approximately 1 Mbps and above, the remote-bridge becomes 
increasingly like the local bridge in its operation; i.e., the thruput, and 
response time can approach that of the local bridge (if TP line lengths are kept 
under 100 Km) . 

Note: Operation of the remote-bridge (R-B) at 1.344 Mbps is very different from 
that at 9.6 Kbps or 56 Kbps because resource utilization is very different. In 
fact, the remote-bridge at 1.344 Mbps operates very nearly the same as the local 
version of the bridge (due to higher line quality, and speed). However even at 
the highest speeds some important differences between the local and remote 
versions of the bridge still exist. These are normal communications consider- 
ations that exist in most long lines situations but may be new to those only 
experienced with locally bridged LANs. Some of the more important differences 
are: 



Line latency (ie. the impact of line length on response time) 



Error re-transmission of a lost frame due to bridge congestion. 

be encountered when a considerable difference exists between 

output speeds. Speed matching via buffering is the normal 

Buffers can be intermittently exhausted during bursty traffic patterns) 

The higher the line speed the less of an issue this becomes. 



(This can 
input and 
solution. 



Note: These are performance tuning considerations not lost data situations 
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Other Performance Consideration and Guidelines 

The remote-bridge's primary mode of operation is expected to be the connection 
of remote users to local resources via a single TP line (1 hop). However, some 
network topologies will require interconnection of peer locations via multiple 
hops. In addition, situations may arise requiring remote-bridges be connected 
in parallel. For instance, widely dispersed Token-Rings may require either full 
or partial interconnection via remote-bridges. Full interconnection means ev- 
ery Token-Ring has a single-hop remote-bridge connection to every other Token- 
Ring in the network. For these configurations, the LLC and remote-bridge 
parameters may need to be changed from the default settings for satisfactory 
operation. 

The remote-bridge, as with the local bridge, can support up to seven cascaded 
hops. A primary example of a requirement for such a configuration might be 
several widely separated peer locations wishing to share resources. In such 
configurations, the key concern is proper setting of the LLC parameters at the 
end stations for maintaining the best overall performance. The primary parameter 
that must be considered is the Tl timer value. An estimate of the Tl timer value 
required for this case is: 

■ Tl(sec) > 2NB/R 

■ Where N is the number of remote-bridge hops (equal to or less than 7) 

■ B is the transmit buffer size (in bits) for the TP line adapter and 
should be selected according to the single-hop procedure discussed in 
the Remote-Bridge Users Guide 

■ R is the TP line speed (in bits per second) 

It should be understood that the above equation provides an approximate 
lower bound for the Tl timer value; the actual operating value should 
be approximately 10 to 20 percent higher. (Note: This estimate has not 
been verified by testing; however, it is thought to be a good approxi- 
mation) 

Parallel remote-bridge connections will, in general, require adjustments simi- 
lar to those applicable to a single remote-bridge, except for possible filtering 
arrangements to control loading on each path. 

The multi-path (parallel bridge) configuration falls into the same category as 
the cascaded configuration. The value of N (the maximum number of hops) used 
in the above equation depends on to what degree the rings are interconnected. 
For example, N should be 1 for a fully connected configuration, or as large as 
1 minus the number of interconnected T-R's. If the maximum number of hops an 
application will use (including alternate, or backup paths) can be easily 
identified, use this number and add 10 to 20 percent to it. If this number cannot 
be easily identified, use 4 and adjust this value either up or down until a 
satisfactory level of operation is achieved. 
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USABILITY AND MANAGEABILITY 

EASE OF INSTALLATION: 

The remote bridge is installed by the customer using a menu-driven installation 
routine. The bridge parameters can be configured locally at the bridge console 
or from the LAN Manager or NetView. 

NETWORK MANAGEMENT 

The remote bridge extends LAN management as transparently as it extends 
connectivity. The remote ring is managed as if it were a local ring, with the 
same commands and automatic notifications to the LAN Manager and, hence, to 
NetView. But, because the remote and local rings appear as one, the LAN manager 
can provide much more information than is available through NetView. Such in- 
formation as error counts and the configuration display for the remote ring can 
be viewed from the central site, allowing complete management of the ring. 

Although the remote bridge does not provide complete management of the TP line 
(LPDA capability) , loss of the TP line can be determined at the LAN Manager and 
NetView. Each half of the remote bridge monitors the TP line and if the line 
goes down, a message indicating the line is down is displayed at the bridge 
console. The LAN Manager will generate an alert which is forwarded to NetView. 

The bridge program maintains several performance counters for each LAN segment 
connected to a bridge. The counters record the following information: 

Broadcast frames forwarded 

Broadcast bytes forwarded 

Non-broadcast frames forwarded 

Non-broadcast bytes forwarded 

Frames not forwarded: target LAN segment inoperative 

Frames not forwarded: adapter congestion 

Frames not forwarded: telecommunication link error 

Bytes not forwarded: telecommunication link error 

Frames not forwarded: filtered 

Frames not routed across this bridge(IBM PC Network only) 

These counter values can be displayed at the bridge station. In addition, the 
bridge provides a performance threshold parameter. The "percent frames lost 
threshold" allows you to identify the maximum ratio of frames received by the 
bridge but not forwarded (due to adapter congestion, target LAN segment inop- 
erative, or other reasons) to the total number of frames received by the bridge. 

The IBM Token-Ring Network Bridge Program V2.1 remote bridge function also 
provides the "telecommunications link error threshold" which indicates the 
maximum ratio of frames not forwarded (due to telecommunications link errors) 
to the total frames received. 
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The bridge programs check the performance counters once each minute to see if 
a threshold has been exceeded. If a threshold is exceeded, a "performance 
threshold exceeded" notification is sent to the IBM LAN Manager V2.0. 

The IBM Token-Ring Network Bridge Program V2.1 acts as a network management 
agent for the LAN segments that it is bridging and reports this information to 
IBM LAN Manager V2.0. Each bridge can forward this management information to 
four different LAN Managers, although only the controlling LAN Manager can 
change some bridge program configuration parameters in the bridge system. 

Changes are stored by the bridge program on disk so that if the bridge shuts 
down and is restarted, the changes are still in effect. Each LAN Manager must 
provide the appropriate password to the bridge program before the bridge will 
accept a link with that bridge. If there are no IBM LAN Managers in the network, 
the default link password values as defined in the bridge program user's guide 
may be used. 

The IBM LAN Manager V2.0 can request and display these counter values. These 
values can be recorded automatically in a disk file each time a specified time 
interval lapses. Also, whenever the IBM LAN Manager receives the "threshold 
exceeded" event, it generates an alert indicating "bridge performance threshold 
is exceeded". This alert is displayed and recorded at the LAN Manager, and is 
sent to the host if a host product (ie. NetView ) is managing the network. 

The IBM LAN Manager V2.0 can manage the bridge using the LINK/UNLINK, CONFIGURE 
and QUERY BRIDGE commands. These commands can also be issued at the host using 
the NetView console. By linking to a bridge, the IBM LAN Manager can also manage 
the "bridged LAN". 

For more details, please refer to the IBM Local Area Network Administrator's 
Guide, and User's Guides shipped with the IBM Token-Ring Network Bridge Program 
V2.1 and the IBM LAN Manager V2.0. 

UNIQUE/EXCLUSIVE CAPABILITIES 

The remote bridge can connect previously separate LANs (islands) into a single 
logical LAN using data communication lines. This is extremely useful to cus- 
tomers who have separate independent facilities that they wish to inter- connect . 
This requires that a global naming/addressing convention be used to maintain 
uniqueness. 

SPECIAL CONSIDERATIONS 

The maximum frame size supported by the remote bridge is 2052 bytes. For op- 
timum performance, however, the maximum frame size values shown in the following 
chart are recommended. 
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516 
1500 
2052 





For those applications which cannot adjust the maximum frame size to the re- 
commended value, operation with the remote bridge is possible by adjusting the 
max frame size parameter at the bridge. Caution should be exercised, however, 
as this may severely impact the link capacity of the bridge. This approach 
should only be used when the use of higher speed lines is out of the question, 
and only then, with very high quality communication lines. 
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III.D. 

3174 TOKEN-RING LAN GATEWAY 

PRODUCT OVERVIEW: 3174 TOKEN-RING GATEWAY FEATURES 

PRODUCT OBJECTIVES 

The 3174 Token-Ring Gateway provides local and remote gateway function between 
the 16/4 Mbps Token-Ring Local Area Network and the SNA Wide Area Network. Its 
objectives are to provide: 

■ Pass through support of SNA PU Type 2.0 and PU Type 2.1 (in migration mode) 
Token-Ring attached devices . 

Note: Migration mode = PU2.1 processed as PU2.0. 

■ Low cost migration from the traditional coax attached fixed function display 
environment to the T-R attached Intelligent Workstation environment. 

■ T-R Gateway support utilizing existing host applications and/or the SNA 
network (i.e., NCP and VTAM) . 

FUNCTION HIGHLIGHTS 

The Token-Ring Gateway function is supported on 3174 Models 11L, 11R, 12R, 61R, 
and 62R via the IBM 16/4 Mbps Token-Ring Network Gateway feature (#3026) or via 
Configuration Support B (#5010, 5060) and the Type 3A Dual Speed (16/4 Mbps) 
Communication Adapter (#3044) . 

The Token-Ring Gateway function is also supported on 3174 Models OIL, 01R, 02R, 
51R, and 52R via the IBM 16/4 Mbps Token-Ring Network Gateway feature (#3026). 
3174 Models OIL, 01R, 02R, and 51R are also supported via Configuration Support 
B (#5010, 5060) and the Type 3A Dual Speed (16/4 Mbps) Communication Adapter 
(#3044). 

Except where specifically noted, the following list of functional capabilities 
applies to all 3174 models which support the Gateway function. 

Token-Ring Support 

■ One 16 or 4 Mbps T-R 

■ Up to 250 T-R attached PUs w/ CS-B1 and the appropriate 3174 models 

■ Essentially unlimited number of LUs 
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■ 256 byte to 4 Kbyte frames 

Multi-Host Token-Ring Gateway 

The Multi-Host Token-Ring Gateway function provides multiple host connectivity 
for T-R attached devices through a single 3174 T-R Gateway. Support is provided 
for either one channel and two TP connections on the local gateway models, or 
three TP connections on the remote gateway models. In all cases, the host 
connections must be to an IBM SNA host. 

The Multi-Host Token-Ring Gateway function is especially useful when used in 
conjunction with 3174 Models X3R. The Single Link-Multiple Host function of 
the 3174-X3R allows the X3R to have up to eight concurrent host sessions (with 
each terminal user accessing up to five host sessions). The hosts can be di- 
rectly attached to the Token-Ring or attached via a Token-Ring Gateway. With 
the Multi-Host Token-Ring Gateway function, one 3174 Token-Ring Gateway can 
provide host connectivity to three SNA host sessions for the terminal users 
attached to a 3174 Model X3R. 

Each additional host connection is provided by the Concurrent Communication 
Adapter feature (#3050, 3051, 3053). Each Concurrent Communication Adapter 
supports up to 50 T-R attached PUs. However, the total number of PUs supported 
by the 3174 gateway is still 250. 

NOTE: The Multi-Host Token-Ring Gateway function availability date is December 
28, 1990. 

Ring Error Monitor (REM) 

the 3174 Token-Ring Gateway supports the REM function for the attached T-R. 
REM collects hard and soft error information about the T-R and reports statis- 
tics to NetView. 

Group Poll Performance Enhancement 

CS-B R.l offers a performance enhancement over previous releases with the in- 
troduction of Group Poll support for the 3174 T-R gateway. 

Given that a 3174 Gateway and all of its T-R attached Down Stream Physical Units 
(DSPUs) appear to NCP as PUs on a multi-drop TP line; the following is a brief 
explanation of Group Poll: 

■ Before the Group Poll enhancement 

■ Frames from a workstation DSPU could only be sent in response to a poll 
to the specific PU controlled by the gateway. 

■ Low transaction rates or large numbers of DSPUs meant that NCP fre- 
quently polled DSPUs with nothing to send while others with data to send 
waited for their specific poll. 

■ High levels of such unproductive polling can cause performance prob- 
lems. 

■ After the Group Poll enhancement 
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■ DSPUs defined to NCP under Group Poll can be polled using the address 
of the 3174 controller. If multiple 3174 T-R gateway controllers reside 
on the line, each would be defined under a separate Group Poll. All 
DSPUs connected to the 3174s are still defined to the NCP. 

■ As NCP encounters one of the gateway PUs in the Service Order Table it 
will issue a Group Poll to the 3174 Gateway. If there is no 3174 T-R 
gateway activity on the line, only Group Polling will occur. 

■ If there is activity, the 3174 will respond and further activity with 
the DSPU at the top of the queue will take place using its PU identity 
as defined in the NCP. This maintains the LU/PU integrity of SNA, un- 
like solutions that re-map DSPUs to a single PU definition in the NCP. 

■ This reduces non-productive polling, improving line utilization and 
performance; while maintaining LU/PU integrity. 

Direct Device Attachment 

In addition to its gateway function, the 3174 T-R Gateway also serves as a 
cluster controller for up to 32 3270 displays and printers and up to 24 ASCII 
devices. Following is the device attachment capability by model: 

■ 3174 Models OIL, 11L, 01R, 11R, 02R, 12R 

32 CUT/DFT 
24 ASCII 

■ 3174 Models 61R, 62R 

16 CUT/DFT 
8 ASCII 

■ 3174 Models 51R, 52R 

16 CUT/DFT 
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MODEL NETWORK DIAGRAMS 



3174 LOCAL GATEWAYS 



The local gateway feature is available on 3174 models 1L and 11L. The feature 
provides an intermediate link to VTAM for each Token-Ring attached PU. The 3174 
Gateway and the T-R PUs appear to VTAM as channel attached PU2s , with each 
having its own sub-channel address. 
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Figure 10. 3174-11L Gateway 
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3174 REMOTE GATEWAYS 

The remote gateway feature is available for 3174 models 1R, 2R, 11R, 12R, 51R, 
52R, 61R, and 62R. The remote gateway provides an intermediate link to NCP for 
each T-R attached PU2. 

The 3174 Gateway and the T-R attached PUs appear to NCP as PU2s multi-dropped 
on a TP line. The gateway responds to NCP polling on behalf of all of the PU2s 
and polling is not propagated over the Token-Ring Network. 
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Figure 11. 3174 11R Remote Gateway 
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MODEL CONFIGURATIONS AND PRICES 

Both the large 32 port and the medium 16 port 3174 models can be used as T-R 
gateways. They support the same number of T-R attached workstations and provide 
the same level of throughput performance. Below are sample hardware config- 
urations for these models: 

3174 Model 61R $6,500 

Cfg. Supt. - B (#5060) 550 

Addtnl 1M Memory (#1012) 2,415 

16/4 Mbps T-R Adap. 3,500 

(#3044) 

Total Price $12,965 



3174 Model 11R 
Cfg. Supt. - B (#5010) 
Addtnl 1M Memory (#1012) 
16/4 Mbps T-R Adap. 

(#3044) 
Total Price 



$10,960 


3174 Model 11L 


$14,260 


1,100 


Cfg. Supt. - B (#5010) 


1,100 


2,415 


Addtnl 1M Memory (#1012) 


2,415 


3,500 


16/4 Mbps T-R Adap. 
(#3044) 


3,500 



$17,975 



$21,275 



ATTACHMENT/CONNECTIVITY 

Upstream Connectivity 

■ One local channel or. . . . 

■ One remote TP, up to 64 Kbps 

NOTE: Support for additional line connections via the Concurrent Communi- 
cations Adapter has been announced with a GA date of 12/28/90. At that 
time, up to 3 host connections will be supported; 1 channel and 2 lines on 
the local gateway or up to 3 lines on the remote gateway. 

■ Protocols: 

SNA/SDLC 
PU 2.0 

Downstream (Token-Ring) Connectivity 

■ One 16 or 4 Mbps Token-Ring 

■ Protocols 

IEEE 802.2 

PU 2/LU 2 

PU 2.1/LU 6.2 (in migration mode) 

■ Supported devices 

PCs or PS/2s running 3270 EP V.3 
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PCs or PS/2s running WSP VI. 1 

PCs or PS/2s running OS/2 EE VI. 1 

PCs or PS/2s running APPC/PC - LU6.2 

PCs or PS/2s running Personal Communications/3270 

3174 Models 03R, 13R, 53R, 63R 

S/36 

AS/400 

9370 with DPPX/370 

PREREQUISITES 

■ 2.5 Mb of memory is required when using Configuration Support B (#5010, 
5060). 

■ 1.5 Mb of memory is required when using the IBM 16/4 Mbps Token-Ring Network 
Gateway feature (#3026). 

■ When taking advantage of the Group Poll performance enhancement, both NCP 
and the System Support Program (SSP) require Small Programming Enhancements 
(SPEs). SPE availability is 9/29/89 via PTFs on the following programs: 

NCP Version 4 Release 3.1 
NCP Version 5 Release 2.1 
SSP Version 3 Release 4.1 

See Ivory Letter 189-069 

PERFORMANCE/CAPAGITY/THROUGHPUT CONSIDERATIONS 

Following are considerations which affect 3174 Gateway performance, capacity 
and throughput. Please refer to HONE document "IBM Establishment Controller 
Performance Data and Guidelines for Configuration Support B Release 1.0" for a 
more detailed discussion and actual performance statistics. 

One or more of the following criteria determines the maximum number of ring- 
attached controllers and workstations that can have access to the host: 

■ The maximum number of SNA Type 2.0 physical units (PUs) defined to VTAM as 
being capable of host access 

■ Performance of the 3174 Gateway when used as a local gateway. 

■ Performance of the telecommunications line when using a 3174 a remote 
gateway. 

The number of Type 2.0 PUs supported on a ring depends on the the amount of 
memory available in the gateway controller. The 3174 Gateway supports a maximum 
of 250 PU type 2.0 devices on a 16/4 Mbps Token-Ring network. Also, a maximum 
Token-Ring frame size of 4105 bytes is supported. 
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The number of 3174 controllers that you may want to attach to a ring is likely 
to be more limited. Transactions between a workstation on a 3174 ring-attached 
controller and the host pass through the following four subsystem layers. 

■ The host channel or the telecommunications link 

■ A local or remote 3174 controller with the Gateway feature 

■ The Token-Ring network 

■ The ring-attached 3174 Model 13R and 53R controllers 

For DSPU-S/370 communication, 3174 Gateway traffic equals DSPU-S/370 ring 
traffic. For a given amount of 3174 Gateway traffic, utilization of the ring 
is less than one- fourth of the gateway utilization. Because of this, some 
peer-to-peer traffic within the Token-Ring itself, will have little effect on 
gateway performance. 

The 3174 Gateway can also be used for concurrent activities such as servicing 
other directly attached NPT and ASCII terminals. Transactions performed by 
directly attached devices utilize the 3174 to a much greater extent than similar 
transactions from device attached via the Token-Ring. Therefore the 3174 
Gateway has a greater transaction through-put for devices attached via the 
Token-Ring. 

The following suggestions can improve gateway performance: 

■ If possible, set SNA pacing to zero to eliminate acknowledgements to out- 
bound traffic. If it is not possible, set it to as high a value as is 
possible to reduce acknowledgements to a minimum. While SNA responses do 
not add much to response time, they do increase significantly 3174 Gateway 
utilization. This results in decreased 3174 Gateway traffic capacity. 

■ If possible, specify an RU size large enough to contain the entire trans- 
mission. This reduces, message segmentation. 

■ In order to reduce frame processing overhead, use the maximum Token-Ring 
frame size (4105 bytes) when transmitting large messages. 

LOCAL GATEWAY 

The following figure provides data on the traffic handling capability of the 
3174 Gateway in a Model 11L. 



III.D. 41 









3174 


Gateway Capacity 




1 


3174 Gateway Utilization 


1 


15 


30 


45 


65 


85 


2 


(4 Mbps) Gateway-ring 
delay, ms 


17 


18 


19 


20 


23 


27 


3 


(16 Mbps) Gateway-ring 
delay, ms 


14 


15 


16 


17 


20 


24 


4 


RTR traffic, A-1200/minute 


- 


737 


1482 


2222 


3228 


4000 


5 


FT traffic, in KB/second 


- 


40 


76 


116 


168 


226 


6a 
6b 


3174-13R CTR=6.7 RT, ms 
3174-13R CTR=214 RT, ms 


107 
119 


108 
120 


110 
123 


112 
126 


119 
132 


136 
158 


7a 
7b 


3174-13R CTR=6.7 RT, ms 
3174-13R CTR=214 RT, ms 


105 
119 


107 
120 


110 
123 


112 
126 


119 
132 


136 
158 



Figure 12. Traffic handling capability for a 3174— Model 11L Gateway 

The following list contains line-by-line explanations of the entries in the 
above chart. 

■ Line 1 lists a range of 3174 Gateway utilizations in percent. 

■ Line 2 shows the contribution of 3174 Gateway plus 4 Mbps Token-Ring network 
delay to A-1200 subsystem response time (inbound plus outbound). 

■ Line 3 shows the contribution of 3174 Gateway plus 16 Mbps Token-Ring net- 
work delay to A-1200 subsystem response time (inbound plus outbound). 

■ Line 4 specifies the Ring Transaction Rates (RTR), in A-1200 transactions 
per minute, associated with the 3174 Gateway utilizations in Line 1, as- 
suming a 16 Mbps Token-Ring. 

■ Line 5 shows the combined File Transfer rates (FT), in KB/second, associated 
with the 3174 Gateway utilizations in Line 1, assuming a 3174- 11L, 4K RUs 
on local channel, and 4105 byte frames on a 16 Mbps Token-Ring. 

■ Line 6a shows subsystem response obtained at a 4 Mbps Token-Ring attached 
3174-13R/3278 controller with CTR =6.7 transactions/minute/device. 

■ Line 6b shows subsystem response obtained at a 4 Mbps Token-Ring attached 
3174-13R/3278 controller with CTR = 214 transactions/minute/device 

■ Line 7a shows subsystem response obtained at a 16 Mbps Token-Ring attached 
3174-13R/3278 controller with CTR =6.7 transactions/minute/device 

■ Line 7b shows subsystem response obtained at a 16 Mbps Token-Ring attached 
3174-13R/3278 controller with CTR = 214 transactions/minute/device 

Because Token-Ring utilization is so much less than 3174 Gateway utilization, 
some peer-to-peer traffic over the ring is not expected to substantially affect 
the above information. 



III.D. 



42 



REMOTE GATEWAY 

The remote gateway supports the same number of DSPUs as the local gateway (250). 
However, the practical number is lower because the gateway traffic is now lim- 
ited by the speed of the telecommunications link (up to 64 Kbps). Because line 
speed dominates performance, utilization of the 3174 Gateway will remain low 
even at high line speeds. 

There are other factors which can affect performance for workstations on a re- 
mote Token-Ring network. These include: 

Size of frames transferred 

Data transaction rates 

Organization of NCPs active polling list 

NCP parameters 

VTAM parameters 

Propagation and modem delays 

Group vs Specific polling 

Following are some suggestions to keep in mind when configuring remote gateways. 

Customize for Group Poll. 

At this time, lines must not be defined as FDX to the NCP when using the 
Group Poll Performance Enhancement. Doing so will result in polling con- 
fusion relative to the T-R resident PUs. This will be addressed in future 
enhancements . 

■ Use Half Duplex Send Priority (HDXSP) as yes. With Send Priority, outbound 
frames for PUs attached to a 3174 are sent prior to NCP polling for inbound 
data from that 3174. 

■ Specify NCP MAXOUT as 7. This will allow a maximum of 7 frames for a PU 
to be sent outbound or inbound during a polling cycle. 

■ Specify NCP MAXDATA as 521 to allow the maximum number of bytes to be con- 
tained within a frame. 

■ Follow the recommendations outlined previously regarding pacing, Token-Ring 
frame and RU size. 

Refer to HONE document "IBM Establishment Controller Performance Data and 
Guidelines for Configuration Support Release B1.0" for a more detailed dis- 
cussion and actual performance statistics. 

USABILITY 

Ease of installation 

The 3174 T-R Gateway is a Customer Setup (CSU) gateway with a relatively simple 
definition/ implementation process. In addition, the 3174 Gateway supports both 
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T-R Burned-In Addresses and Locally Administered Addresses for ease of instal- 
lation or enhancement to system security. 

Network Management 

On-line diagnostic tests and error logs for coax attached workstations 

Full Ring Error Monitor (REM) support 

PU pass through support of the LAN Manager 

PU/LU session level alerts to NetView 

Vital Product Data (VPD) for directly attached workstations 

Central Site Customization Utility (CSCU)/Central Site Change Management 
(CSCM) for microcode maintenance and upgrade 

Central Site Control Facility (CSCF) for remote problem determination in- 
cluding access to REM 

Pre- definition of T-R Devices 

By anticipating growth in T-R device support, the customer can predefine a 
number of T-R devices greater than the actual number of devices initially at- 
tached. Then, as devices are added to the ring, the only requirement is to 
ACTIVATE them via NCP. 

UNIQUE FUNCTIONS 

Central Site Customization Utility (CSCU) 

CSCU allows the customer to configure and distribute via diskette the 
customization for his network 3174s from a central site 3174. This function 
can offer significant savings in the time and travel associated with updating 
and maintaining remote 3174s. 

Central Site Change Management (CSCM) 

CSCM, in conjunction with the NetView Distribution Manager, allows the customer 
to up- load and store in the NetView DM library the customization data from the 
CSCU. The NetView DM database will also store a complete copy of the 3174 Li- 
censed Internal Code (LIC) and copies of the DSL microcode for 3174 attached 
Intelligent Workstations (IWSs). Once stored, NetView DM can automatically 
distribute this data to any or all network 3174s via the host link connection. 

Central Site Control Facility (CSCF) 

CSCF allows a NetView operator to access the 3174 On-line Diagnostic Tests (/ 
Tests). These include: 

■ Display Token-Ring REM Logs 

■ Display Event and Response Time Monitor Logs 
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■ Display Configuration Panels 

■ Display and Enter Vital Data 

■ Reset Logs and Cable Errors 

■ Retrieve Trace Data 

CSCF provides centralized access to the key on-line problem determination tools 
of the 3174 and can reduce or even eliminate travel to remote 3174s in the event 
a problem occurs . 

NOTE: The 3174 Central Site Control Facility requires that the NetView CSCF 
feature be installed on NetView. 

Direct attachment of CUT/DFT/ASCII workstations 

The 3174 T-R Gateway supports direct attachment of 3270 NPTs (Non-Programmable 
Terminal) and ASCII workstations. This function is particularly important in 
small to medium sized remote establishments which are migrating from coax only 
attachment to mixed coax and T-R attachment. The migration is very cost ef- 
fective with the installation of the Token-Ring Gateway feature on the remote 
3174. 
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III.E 

IBM 3745 COMMUNICATION CONTROLLER 

OVERVIEW 

PRODUCT OBJECTIVES 

The 3745 family of Communication Controllers provides a versatile set of SNA 
Network gateway facilities . The provide both channel attached and remote SNA 
access to a S/370 hosts for a variety of down-stream connections. This dis- 
cussion will focus on the Token-Ring gateway facilities accessed via the 3745s 
Token-Ring Adapter (TRA) . 

All 3745 models provide communications traffic routing between: 

■ Workstations on a Token-Ring and S/370 based applications 

■ S/370 processors at the same and/or different locations via: 

■ TP lines (NCP-INN Transmission Groups, etc.) and/or 
Token-Rings (NCP-INN Local and/or bridged LANs) 

■ APPN Application Processors/Sub-Networks (via SNA/LEN-PU2. 1 routing sup- 
port) 

FUNCTION HIGHLIGHTS: 

The 3745 complements S/370 processors by reducing (or eliminating) the impact 
of communications resource management on application processing resources by 
executing such tasks within the 3745 . 

The 3745 also incorporates comprehensive network management facilities and 
significant high availability features within its function set. 

Where access to multiple hosts/sites (local and/or remote) is required, the 3745 
is justified by its extensive connectivity options, integrated availability 
features and attachment capacity. 

The individual 3745 models provide the following connectivity: 

■ 3745-130: Specialized Communication Controller: 

■ Host-to-host(s) high speed interconnection 

■ Remote Token-Ring LAN attached devices via SNA Tl support 
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■ Local Token-Ring LAN attached devices via SNA Channel Attachment 

■ 3745-150: Specialized Communication Controller: 

■ Remote concentration of low and medium speed links 

■ Remote Token-Ring LAN attachment 

■ Combinations of both 

■ 3745-170, 210 & 410: General purpose Communication Controllers: 

■ Medium (170) to high (210/410) performance levels: 

■ Remote &/or Local attachment of data links 

■ Remote &/or Local gateway facilities for Token-Ring LANs 

■ Host to host high speed inter- connect ion 

■ All IBM 3745 Models can act as remote access nodes, concentrating attached 
link and/or T-R LAN traffic onto one or more high speed communication lines. 
The 3745s may be interconnected via communication lines operating at speeds 
up to 1.544Mbps (Tl) or 2.048 (CEPT *) . This type of high speed concen- 
tration helps to reduce overall communication costs while enabling high- 
volume transmission and rapid response times. 

(*)CEPT = Conference of European Postal Telecommunications Administration 
MODEL NETWORK DIAGRAMS 
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Figure 13. 3745 Gateway Example (Local and Remote) 
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MODEL CONFIGURATION AND PRICES 

Any 3745 model, from 3745-130 through 410, can be used in local (channel at- 
tached) or remote environments, as LAN gateways. The models 130 and 150 are 
normally the most cost effective in remote sites. The model 130 is specifically 
designed to support 1 or 2 high speed (Tl) and 1 to 4 Token-Ring LAN attachments. 
The model 150 is optimized to support up to 16 medium speed lines and up to 2 
Token-Ring LAN attachments. Sample hardware configurations of the 3745 models 
130 and 150 are shown below: 

A 3745-130 configured to support 2 Token-Rings and 1 Tl line: 



3745-130 


$20,000 


High speed scanner 


20,000 


Token Ring Adapter 


7,500 



Total $47,500 

A 3745-150 configured to support 2 Token-Rings and 2 64Kb lines: 



3745-150 


$29,500 


Token Ring Adapter 


7,500 


2 Line Interface Type 3 


5,730 



Total $42,730 

Note: These prices are hardware only; the cost of NCP must be added. The Tier 
1 through Tier 2 NCP prices range from $15,870 to $23,805. This is appropriate 
for low end remote T-R gateway configurations. Larger more complex configura- 
tions will require the appropriate NCP Tier level with its associated price. 
Tier levels range from 1 to 5. 

ATTACHMENT/CONNECTIVITY 

TOKEN-RING SUPPORT ON THE 3745: 

3745 models attach from 1 to 8 Token Ring LANs at 16/ 4Mbps . The 3745 fully 
supports the Early Token Release option. This option allows improved 16Mbps 
T-R LAN utilization, particularly on long rings with short I-FRAME traffic. 
In addition the 3745 provides: 

Channel Attached (Local) access to S/370(s) 

Remote Gateway/Concentration at up to Tl speeds 

Up to 9999 PUs definable in one NCP Load Module 

NCP frame size definition from 256 to 16,732 Bytes (MAXTSL) 

NCP handling both INN and BNN traffic over the same TIC 

Support for 2 TICs using the same address on the same T-R 

TIC swapping 
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Figure 14. 3745 Attachment Capacity Chart 
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In some Data Center environments, access to several S/370 hosts is a common 
requirement, the models 130 and 170 can attach to 4 different hosts channels. 
For larger requirements the 3745 models 210 and 410 can provide attachment of 
up to 16 different host channels. 

The 3745 has a storage capacity of 4 MBytes for models 130/150/170 and 8 MBytes 
for models 210/410. This storage allow the definition of a large network to 
meet the connectivity requirements of most medium or large establishments. 

3745 LOCAL/REMOTE BASIC TOPOLOGY LAYOUT 

With the various models and associated features, as shown above, a 3745 gateway 
solution can accommodate traffic from the Token-Ring LANs with traffic from TP 
lines, routing data to multiple destinations, either to local hosts or cross 
network to multiple sites: 
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NOTE 1. 3745 to 3745 INN connections (Local on Remote) may be 
established via communication lines or Token-Ring(s). 

NOTE 2. Requires PU2. 1 device attached via NCP-LEN/PU2* 1 support. 

Ceg. APPC/PC-2.1 — ►3745/NCP/LEN — ►AS/400-2.1 — ►LAN— ►APPC/PC) 



Figure 15. 3745 Topology Chart 
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PERFORMANCE/CAPACITY/THROUGHPUT CONSIDERATIONS 

As a remote node in an SNA network, the 3745 has features which can improve 
throughput and provide low response times for remote workstations: 

■ A remote 3745 acts as a boundary network node (BNN). This allows the remote 
3745 to perform boundary node segmentation, polling and error recovery for 
its downstream attached links. This off-loads these tasks from the upstream 
S/370-3745. This also results in improved performance on the upstream INN 
link by reducing the amount of traffic flowing across the line. For a given 
line speed, a 3745 INN link will generally have more user data flowing over 
the line than a non-3745 implementation. 

■ Various techniques implemented by the NCP such as Transmission Groups, dy- 
namic adjustment of the transmission windows, Modulo 128, etc., assist in 
maintaining optimum resource utilization of both local and remote re- 
sources. (Refer to Tuning the Tl on 3745 by R. Deutsch, WSC) 

■ The 3745 INN links are full duplex. In an environment where the traffic 
flows both ways, this will result in higher overall throughput compared to 
a half duplex line. 

■ The data rate is independent of the distance, i.e. there is no propagation 
delay impact. For example, a 3745-130 can maintain a Tl data rate between 
sites thousands of miles apart. This is true for simultaneous traffic, in 
both directions, over the Tl circuit. 

■ Traffic from various sources (including multiple Token-Rings can share the 
same INN link(s), in route to different S/370 hosts. 

■ Routing is done by NCP within the 3745. Each S/370 host handles only the 
data it processes. In a remote environment, the destination is selected 
by the 3745 LAN gateway using the preferred network route. 

■ The Data Streaming capability of the Channel Adapters make it possible to 
install the 3745s at distances up to 120 meters from the host without 
downgrading the thruput on the channel. 

■ The "Tl clear channel" implementation of INN links with the high speed TR 
LANs virtually eliminates network delays for interactive traffic, approxi- 
mating "local" response time. 
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PERFORMANCE SCENARIOS FOR 3745 



ASSUMPTIONS: 



3745 Controller: 
Model 210 or 1X0 
16 Meg TICs 
Multiple TICs attach 
to the same T-R LAN 



NCP parameters: 

Maxtsl .. 16 Kbytes 

Virtual route pacing. . 1/6 
Definite Response . . 6 out of 
10 transactions generate a DR 



Run A-Inter-active transaction processing: 40-1400 byte transactions 

1-LOCAL GATEWAY: (WS«« TR ►3745-4 ►Host) 
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Transactions/second 118 90 

Thruput (KBytes/second) 170 130 

TICs required 2 2 



2-REMOTE GATEWAY: (WS< 
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Transactions/second 113 84 
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Transactions/second 39 
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TICs required 2 
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(a) - Throughput limited by bus utilization of 80 percent. 



Figure 16. 3745 Performance Scenarios 



The performance figures given above have been computed using the 3745 perform- 
ance model. They reflect reasonable expectations but may vary depending upon 
line speeds, protocols, traffic characteristics (such as message length and 
frequency), and other transmission parameters. Refer also the HONE DOCID: 
G042150 for more information on parameters influencing data rates on 3745s. 
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USABILITY AND MANAGEABILITY 

NETWORK DEFINITION: 

■ Large memory size, multiple TICs, switched resources definition and large 
numbers (up to 9999) of network addressable units go together to minimize 
network definition and change: 

■ Each TIC is associated with multiple logical lines corresponding to 
switched PUs which need not exist at the time the network is installed 

■ When a new device is added on the ring, its definition is added to the 
VTAM list, and the VaryNet Act will associate it on the first available 
logical line of the TIC. 

This reduces to a minimum the need to SYSGEN new NCPs . In addition: 

■ It is now possible to down- load (or up- load) the new NCP load modules (GENs) 
to the 3745* s hard disk without disrupting the normal traffic. The new load 
modules can be activated later. Since the previous load module can remain 
on the disk it provides back-up (to the previous configuration level) in 
case of an error in the new module. 

■ With the new version of NCP (supporting the 16/4Mbps TIC), it will be pos- 
sible to attach via the same Token ring for both BNN and INN traffic, si- 
multaneously, on the same TIC. This will simplify topology, physical 
installation and increase connectivity with less hardware. 

NETWORK MANAGEMENT: 

The 3745 performs automatic PD (Problem Determination) procedures when anoma- 
lies are detected and then issues Generic Alerts that can trigger automated 
operators (e.g. select an alternate route). This, coupled with the other in- 
tegral CNM facilities, provides a high-availability platform for managing the 
T-R gateway process. 

■ Network operations can be automated via the NetView licensed program running 
in a host processor. 

■ The 3745 is designed for full remote and unattended operations. This is a 
critical item for sites where available skill are limited. For instance, 
if a power failure occurs, the 3745 will reload from the hard disk when the 
power returns. Full operations could resume without human intervention. 

■ Scheduled power on complements unattended operations in remote environ- 
ments . 

■ The IBM 3745 design provides for customer participation in problem deter- 
mination and repair. For example, customer personnel might replace a 
failing Line Interface Coupler (LIC) or cable without waiting for a service 
call. This helps to reduce down time in critical situations. 

■ The Remote Service Facility (RSF) also assists in minimizing disruption 
since the CE can be dispatched with properly identified replacement parts. 
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RSF service, allows IBM product specialists at the Hardware Support Center 
to contact a specific 3745 for the purpose of remotely monitoring its op- 
eration, diagnosing problems and promptly transferring microcode fixes. 

USABILITY FEATURES: 

■ Both subarea and peripheral node communication can flow over the same TIC 
port. 

■ Port swapping between medium-speed communication line interfaces or between 
IBM Token-Ring ports allows failing ports to be easily bypassed. 

UNIQUE/EXCLUSIVE CAPABILITIES 

There are two significant areas upon which this discussion is based. They are 
the 3745/PU4 SNA network facilities and its versatile support of multiple and 
varied gateway functions combined in one product. 

■ The SNA architecture has defined various functions of major importance in 
meshed networks. These are implemented by the 3745/NCP: 

■ Transmission Groups -- for increased bandwidth and availability between 
network nodes 

■ Alternate routing -- to avoid failing nodes in the network 

■ Pacing and flow control -- to optimize traffic on network trunks and 
minimize the impact of congestion, etc. 

■ Logical separation of BNN and INN traffic --to minimize the impact on 
the network of control information (over-head) 

■ Logical multiplexing of various I/O traffic on SDLC links -- to allow 
optimum utilization of the INN bandwidth under varying traffic patterns 
(bandwidth management) 

■ The 3745 controller supports various types of gateway function in the same 
hardware, eliminating the need to manage multiple boxes: 

■ NPSI -- providing X.25 access to SNA applications (conversion) 

■ XI -- providing transport of X.25 data communications traffic to an 
other X.25 based facility, via an SNA backbone network 

■ NTO -- for converting/enveloping ASYNChronous ASCII and BSC traffic 

■ NEF -- for converting ALC traffic 

■ NSI -- for transporting BSC data over the SNA INN lines 

■ Other unique capabilities are described in the System Availability and the 
Usability chapters. 
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SYSTEM AVAILABILITY 

■ Two TICs can have the same TIC address. This can be used to provide auto- 
matic back-up in case of a hardware failure. It can also be used for dynamic 
load balancing. 

With NCP V5R3 two TICs on a 3745 BNN connection can have the same MAC 
address on the T-R. The inbound route is selected by the first path 
(using remote or local bridging) answering the test command. The NCP 
alternates outbound activity over both TICs. 

Local/Local or Local/Remote configurations of 3745 to 3745 INN commu- 
nications are able to provide non- disruptive route switching via mul- 
tiple bridged LAN connections. Upon a failure of one of the INN bridged 
routes the NCP will: 

■ Hold the logical connection 

■ Find the alternate INN route (via test commands) 

■ Release the prior logical connection if an alternate was found 

■ When communication with a Token-Ring node is lost, NCP will attempt to re- 
establish routing for the logical connection before the link is made inop- 
erative. If alternate routes are available and the node is still active 
on the ring, normal communication will continue. 

■ A spare TIC can be installed to backup several other TICs. The port swap 
(initiated from the 3745 operator console), causes NCP to change the re- 
quired fields, allowing re-establishment of sessions lost due to a TIC 
failure. 

■ As a LAN gateway, the IBM 3745 exploits the availability characteristics 
of its SNA/PU4 implementation: 

■ Multi-link Transmission Group (TG) facilities make the failure of a 
single line transparent. The traffic to the backbone is redistributed 
on the remaining line(s) without disruption. 

When a 3745 with the Two Processor Switch (TPS) is attached to an MP 
(Multi-Processor) S/370 configuration both availability and performance 
can be enhanced. Either leg of the two channel switch can service the 
full MP configuration if the other failed. Also, even though both legs 
may be available unnecessary switching between legs to service alter- 
nating requests is avoided by servicing the request on the currently 
active path. 

■ Session Continuation permits restart and activation of host owned re- 
sources on the LAN, without disruption of active sessions. 

■ The 3745 utilizes highly reliable, advanced technologies which signif- 
icantly reduce the number of cards and connectors per functional com- 
ponent. New capabilities were added to limit outages in case they do 
happen: 

▲ Concurrent diagnostics allow most components to be diagnosed (any 
Model) and/or replaced (on Models 210/410) while the 3745 continues 
in operation. 
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a The automatic Load or Re- load of NCP from the hard disk minimizes 
temporary outages (e.g. loss of power). When necessary, restart 
can be accomplished from a backup load module if, for instance, the 
failure was caused by an error in the newer load module. 
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Figure 17. High Availability Example 



Upstream each TG would be routed to separate 3745/Host facilities, perhaps lo- 
cated at different sites (ie. a backup site). Each leg of a given TG could also 
be routed over separate carrier or TDM paths. 
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IV. PRODUCT SELECTION SCENARIOS 

OVERVIEW 

This section lays out four Token-Ring gateway scenarios that build on the in- 
formation in the previous section. The purpose of these scenarios is to show 
what questions customers are asking and to provide the best solution(s) for a 
given environment. 

Within each scenario, a description of the Token-Ring gateway requirements and 
an overview of the customer's environment, including installed equipment and 
future directions, are given. Second, a schematic shows the different Token- 
Ring gateway options available to the customer. Third, a list of the key de- 
cision criteria used to make the decision and eliminate the other alternative(s) 
is given. Fourth, the solution for the given scenario is presented along with 
alternative solutions that would have worked if specific conditions were 
changed. Finally, if any exceptions to the decision/solution exist, they are 
discussed. 

The four scenarios are: 

■ LAN to Host via channel . 'LAN to host' means that local T-R LAN attached 
devices require access to S/370 host applications. This scenario involves 
a decision on what channel attached Token-Ring gateway to use. The choices 
are the 3174 Subsystem Control Unit or the 3745 Communication Controller. 

■ LAN to Host via TP links . 'LAN to host' means that remote T-R LAN attached 
devices require access to S/370 host applications. This scenario involves 
a decision on what SNA link attached Token-Ring gateway to use. The local 
controller is a 3745, but the remote gateway could be a 3174 Subsystem 
Control Unit, 3745 Communication Controller, DOS Personal 
Communications/3270 Gateway (PC/3270) or OS/2 EE Communications Manager SNA 
Gateway (OS/2 SNA). 

■ LAN to LAN . 'LAN to LAN' means that LAN attached facilities on one Token- 
Ring need to access other LAN attached facilities attached to different 
Token-Rings. This scenario evaluates using Remote Bridge facilities to 
interconnect two or more Token-Rings. S/370 host traffic is routed via a 
local 3745 gateway and its attached Token-Ring. This solution is in con- 
trast to using a remote gateway/TP link solution, as in the preceding sce- 
nario. 

■ TP links to Host . 'TP links to Host' means that link attached devices need 
to access a S/370 application. This scenario goes beyond the question of 
Token-Ring gateway function. This scenario examines the best solution for 
the combined requirements of both Token-Ring and communication line 
connectivity. This is a requirement that is often seen in current customer 
environments . 
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Note: When reviewing Scenarios 1 through 4, the potential for one scenar- 
io's solution to be valid in another scenario may become obvious. Many more 
scenario subsets could have been developed. However, Scenarios 1 through 
4 were selected due to their broad representation of the issues. 

The scenarios have been simplified to eliminate information that is not relevant 
to the solution. Secondly, a specific solution may not satisfy all of a cus- 
tomer's requirements, so a combination of solutions may be needed (e.g. OS/2 
gateways at small sites, 3745 gateways at larger sites). 

These scenarios consider only the basic functions of the products in order to 
provide a "quick look". This analysis is primarily a qualitative, not quanti- 
tative, assessment. For specific quantitative criteria, refer to the informa- 
tion and charts in the previous section. 

Throughout this section, it is important to keep each product's design point 
in mind while assessing each scenario. The 3745's objectives are to control 
link attachments and/or Token-Rings and to do this in a manner consistent with 
backbone network requirements (ie. PU4) . The 3174's objectives include control 
of coax attached NPT (Non-Programmable Terminals) and/or asynchronous link at- 
tached devices and/or Token-Ring connected devices . When active the DOS PC/3270 
gateway task is the only task active, whereas the OS/2 EE gateway task runs 
concurrent with other PS/2 (or PC) tasks. Finally, the Remote Bridge's only 
objective is to inter-connect Token-Rings. 
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SCENARIO #1: LOCAL LAN TO S/370 HOST VIA LOCAL GATEWAY 

■ Description . The customer will be installing a Token-Ring at their data 
center site. They need a Token-Ring gateway that will channel attach to a 
host, and want to know whether to use a 3174 or 3745. 

■ Overview . This customer has a large stand-alone data center with four hosts 
and multiple channel attached 3745s and 3174s installed. Their headquarters 
building is five miles from the data center. They have remote business 
locations throughout the United States. Each remote business site, and 
headquarters, is linked to the data center. These communication links are 
critical to remaining competitive; Staffing at the data center is constant, 
as the customer is investing more in hardware and software to offset the 
need for additional programmers. The company is growing primarily via ac- 
quisition of other companies. 

This is their first Token-Ring installation, and is a limited project de- 
signed to increase their understanding of the T-R LAN environment. Know- 
ledge gained from this project will probably be used to assess future 
Token-Ring LAN projects. The corporate direction is to improve response 
times via high speed media, reduce costs through the use of workstations 
and realistically control their growing communication costs. The project 
will install 75 PCs and PS/2s on a Token-Ring using either a 3174 or 3745 
gateway. It will support the programming staff's access to the MVS/TSO 
development/test machine. 



S/370 
Application Host 



LOCAL 
GATEWAY 



Local Token-Ring 



S/370 Channel 



LOCAL G'WAY 
OPTIONS: 

3745 

3174 



^~~1 — J — J 1 J T 



Workstations are PS/2s or PCs 



Figure 18. Local LAN to S}370 Host 
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Decision Criteria for a local Token-Ring gateway: 

■ Host channels . The 3745 can attach to up to sixteen host channels. 
If available channel attachments were limited (ie. one), VTAM could 
still route traffic via SNA to adjacent S/370s (via 3745/NCP or VTAM 
Channel-To-Channel) until the desired host is accessed. This type of 
CPU pass- through can effect response and availability. Therefore, if 
the 3174 's access requirement is predominantly to its directly attached 
host the 3174 Token-Ring gateway is an excellent choice. If direct 
channel attachment to a number of hosts is required (ie. response 
time/availability requirements do not allow multiple hops etc.) a 3745 
gateway, with multiple channel adapters, is more appropriate. 

■ Number of users . The number of users (PUs) that will simultaneously 
use the Token-Ring gateway is critical. With direct attachment of the 
PCs and PS/2s to the Token-Ring, each device is a PU. With the SNA coax 
implementation, each 3174 controller was a PU, and the coax attached 
PCs and PS/2s were merely LU devices. The T-R implementation associates 
each PS/2 (or PC) with a PU. This requires more S/370 resources and 
can become an issue with, smaller S/370s. However, with MVS/XA based 
systems, it becomes a non- issue. 

A 3174 gateway can support medium to large user groups, however, the 
3745 can provide for an extremely large number of users (PUs). 

■ Throughput requirement . The 3174 can handle high traffic volumes on 
the Token-Ring and is relatively free from contention with other devices 
on the same controller. 3745s handle very high traffic volumes on the 
Token-Ring. However, in some situations the 3745 is also servicing 
other facilities such as: Tl links, EP/NCP links and channels, NPM 
monitoring, etc.). If the 3745 configuration is adequate, there is 
normally no problem. However, in some heavily loaded, mixed environ- 
ments, contention becomes an issue. In such cases the Token-Ring 
traffic should be isolated from the loaded network by dedicating sepa- 
rate 3174 or 3745-130 resources to the site. 

■ Configuration Stability . The 3174 provides an excellent solution for 
stable Token-Ring environments. However, in environments involving 
heavy moves and changes to the T-R population, the impact on system and 
support staff becomes significant. This involves re-customizing the 
3174, and updating MVS and VTAM. The 3745 provides a more moderate 
solution for changing environments. Token-Ring changes do not require 
NCP generations, only a change to VTAM tables that can be made while 
VTAM remains active. 

■ Installed equipment . If the customer has a 3174 or 3745 installed, with 
enough capacity, the cost of upgrading is normally less than adding 
3174s or 3745s. Both the 3174 and 3745 can be field upgraded, in this 
respect. 

Solution . If direct channel access to multiple hosts is required the 3745 
is the appropriate solution. Since this is not an issue in this case, the 
3174 is the proper choice. With four hosts and multiple 3745 controllers, 
their network is quite large and complex and current 3745 resources are best 
dedicated exclusively to that task. Second, in this data center, one host 
is dedicated to program development and testing. Therefore, a 3174 Token- 
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Ring gateway with one channel connection is more than adequate. Third, on 
a unit to unit comparison basis, the price, performance and ease of in- 
stallation of the 3174 exceeds that of the 3745. In many cases, where the 
of number of users is larger and moves and changes becomes a factor, the 
3745 provides the better price performance. Finally, since the gateway will 
only be used programmers with little or no need to transit the network, 
there is no need for that specific 3745 capability. 

Under different conditions the 3745 might be a better solution than the 
3174: 

■ If more capacity was available on an installed 3745 than on 
installed/on-order 3174s. 

■ If the programming staff was constantly changing (employee turn-over, 
location changes, etc.). 

■ The long term customer strategy should be considered. If this project 
was really a small part of a larger effort the solution might need to 
be reconsidered. Perhaps an additional 3745 could handle the entire 
project or numerous 3174s might be needed to complete the project. 

■ If the network required additional networking facilities (line concen- 
tration, multiple remote/local host site connectivity, etc.) the 3745 
would be the appropriate solution. 



IV. PRODUCT SELECTION SCENARIOS 60 



SCENARIO #2: REMOTE LAN TO S/370 HOST VIA TP 

■ Description . The customer is looking for a Token-Ring gateway solution to 
provide host access for Token-Ring attached PS/2s and PCs. AS400s are 
currently on order and the workstations must have access to AS400 applica- 
tions co-resident on their T-R. There is currently no need for workstations 
to access facilities on other Token-Rings or AS400s in the network. The 
customer also requires workstation access to the S/370 3270-VTAM based ap- 
plications . 

Should they use the Personal Communications/3270 Gateway (PC/3270), OS/2 
EE Gateway, a 3174 or a 3745? 

■ Overview . The customer has small sales offices scattered throughout the 
United States. Most sites are small company offices that will use S/370 
applications for incidental file transfer. Larger sites (up to 40 people) 
require access to CICS query/update applications. The customer wants to 
use LU6.2 (APPC) in the near future to simplify document creation and 
processing activities that are currently handled at each office (using phone 
calls and mail/fax services for verification activities). The LU6.2 ses- 
sions will require access to host CICS applications and at some point in 
the future, access to LAN servers at other locations. 

The customer currently has multiple stand-alone clusters in their network. 
They are moving towards a centralized network by providing host access to 
all of their remote sites. There are several hundred users throughout the 
United States, located in offices of 1 to 40 people. The users require 
reasonable response time to support the S/370 based interactive applica- 
tions. File transfer times are not as much of an issue. 

The users primary application facilities will eventually be provided by the 
co-resident AS/400s. The AS/400 work load will be intensive document 
processing. Much of the load will come from NPT devices directly attached 
to the AS/400. The customer has stated that host access (by T-R attached 
workstations) is not to impact the AS/400 application response time. 

The customer wants to manage the network using NetView. They also would 
like to use an X.25 Value Added Network for connection of some of the 
smaller remote locations. 
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■ Decision Criteria for a remote Token-Ring gateway: 

■ Cost . Evaluating the alternatives based on cost provides a logical 
progression from the DOS and OS/2 solutions through the 3174 and 3745. 
Cost is best looked at by starting with the smallest PC solution that 
meets the customer requirements and progressing up to the 3745. The 
PC/3270 gateway is the lowest unit cost solution but other consider- 
ations may have an impact. 

■ Additional Functions . If functions besides the Token-Ring gateway are 
required, these should be used to select the appropriate gateway. For 
instance, if multiple concurrent programs are needed, then an OS/2 EE 
Gateway is the solution. If direct attached (coax) terminals and/or 
ASCII protocol conversion is needed, the 3174 is the answer. If there 
is the need for a high-speed upstream connectivity a 3745 might be re- 
quired. If different downstream facilities (BSC, SDLC, etc,) must be 
concentrated, the 3745 is the answer. In this case, the X.25 VAN 
connectivity requirement for some locations is key. 

■ S peed of Upstream Links . Looking at the response time criteria, the 
upstream link, not the Token-Ring, is the bottleneck. Again, PS/2s (or 
PCs) support lower speeds; the 3174 - medium speeds; and, the 3745 - 
high speed link(s). The 3745 allows multiple links to be used to pro- 
vide multiple active paths to the same host site for increased avail- 
ability and performance. It should also be noted that OS/2 EE's X.25 
facility supports an upstream, full duplex connection at speeds up to 
64Kbps . 

■ Number of Users . The number of users limits the solution; from small 
to large, from a PC to the 3745. However, the number of users involved 
in this case can probably be satisfied by any of the remote gateways. 
This should be validated by the appropriate configurator or SNAP/SHOT. 

■ Solution . The OS/2 EE Gateway solution should be used for all of these 
sites. The OS/2 EE Gateway is the only one that supports T-R host access 
via X.25. A mixed set of gateway solutions could be used but adds to the 
complexity. This way, those workstation requiring the X.25 support use the 
same gateway as those attached via SLDC. 

The number of users, at each site, is appropriate to an OS/2 EE solution. 
In addition, the OS/2 EE Gateway can run the LAN Server, Data Base Manager 
and LAN Manager simultaneously. 

The customer's LU6.2 requirements are for sessions between a PS/2 (or PC) 
on the T-R LAN and CICS. If they required T-R to T-R as well as host access 
other solutions would need to be examined. The T-R Remote Bridge would 
become a candidate (requiring a T-R gateway at the S/370). 

■ Under different conditions (and given no X.25 requirement) other gateways 
could provide a better choice. 

■ If a PS/2 with DOS was already in use at some locations, and the gateway 
could be used at times that did not interfere with its other use, the 
PC/3270 gateway could be used. This might require the use of one of 
the memory management programs discussed previously. As the customer 
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migrated to PS/2s, PC/3270 Gateways could be replaced by OS/2 EE Gate- 
ways. 

■ At sites with more users and higher line speed requirements a a 3174 
solution might be more appropriate. 

Exceptions . If there are departmental systems located at the remote sites 
they could act as the T-R gateway. Departmental systems can easily provide 
excellent T-R gateway facilities; given that T-R gateway loads would not 
interfere with other activities too greatly. Since these systems provide 
application processing as their primary function, they are normally not used 
to provide just the gateway task. 
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SCENARIO #3: REMOTE LAN TO LAN AND S/370 HOST 

■ Description . The customer is looking for a remote Token-Ring gateway sol- 
ution (similar to Scenario #2) or a Remote Bridge solution, that will allow 
remote Token-Ring devices to access host applications and existing Token- 
Ring services at the host site. Should they use a remote gateway or a Remote 
Bridge configuration? 

■ Overview . The customer is a large firm with an IBM host and a 3745-170 
installed at the data center. The 3745 supports 28 lines and a local 
Token-Ring, which handles the corporate engineering department. They would 
like to connect their remote engineering sites to the main data center site, 
to provide high-speed LAN-to-LAN access between all sites, and LAN-to-S/370 
access from all sites. These remote sites are currently stand-alone islands 
of departmental Token-Rings using high volume graphics files and print 
server functions. They use Token-Ring attached PCs for graphics design 
applications, 3174 coax attached 3270 terminals for text/specification work 
and PS/2 model 80s as file servers. 

Twenty percent of the Token-Ring traffic will be LAN-to-host to access a 
CICS/GDDM application and the remainder of the traffic will be LAN-to-LAN, 
to access file servers (e.g. specification files) on different LANs. In 
addition, some of the traffic on the T-R will require the use of non-IBM 
protocols (ie. Ethernet) 

The customer is quite familiar with LAN technology and management, but has 
limited SNA skills from their 28 line SNA network. Currently, they have 
Tl-TDMs (IDNXs) managing bandwidth for voice and data. They plan to exploit 
the cost reduction opportunity presented by the new Fractional Tl services. 
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■ Decision Criteria for a Token-Ring gateway versus a Remote Bridge solution 
is cost and transparency. The Remote Bridge is a simple, inexpensive sol- 
ution aimed at both LAN-to-host and LAN-to-LAN requirements. 

■ Network management . NetView along with NCP provides broader network 
management facilities than LAN Manager. This is significant when mixed 
networks of communication lines and Token-Rings are involved. However, 
in that mixed environment LAN Manager is required at the remote 3745 
sites as well as S/370 3745 (non-bridged) sites, to provide the T-R 
alerts to NetView (via 3745/NCP) . If only Token-Ring facilities are 
involved, LAN Manager provides the facilities for centralized manage- 
ment. However, in most S/370 environments the combination of LAN Man- 
ager and NetView provides a more appropriate set of centralized 
management facilities. 

A 3745 gateway provides transmission groups (TG's) which support mul- 
tiple host links to improve availability (reducing session outages), 
whereas the Remote Bridge provides multiple, but unrelated, bridge 
links for redundancy and load balancing. 

■ Session management . If the traffic is high volume and bursty then 
VTAM/NCP pacing and flow control is an excellent means of maintaining 
performance levels. Since these facilities are hot provided by the 
Remote Bridge, sufficient bandwidth must be available to avoid the 
problems normally addressed by pacing and flow control. The higher the 
line speed the less of issue this becomes. 

■ LAN-to-LAN traffic . If traffic is predominantly LAN-to-LAN, the Remote 
Bridge is the appropriate solution. If traffic is predominantly 
LAN-to-S/370, either a Remote Gateway or a Remote Bridge provide is 
appropriate depending on the other factors involved. 

If additional protocols need to be supported within the network, a Re- 
mote Bridge solution allows for various facilities attached to one LAN 
to communicate with similar facilities on another. Using the 8209, 
Ethernet protocols can flow to Token-Ring resident facilities (given 
compatible protocol stacks) or off the T-R to another 8209/Ethernet 
facility. This level of protocol transparency is important in many LAN 
situations currently being encountered. 

■ Customer skill level . If the customer has only SNA experience, a 
gateway solution may be preferable. If the customer has only LAN ex- 
perience, the Remote Bridge may be the better solution. However, cer- 
tain aspects of the solution may be significant enough to justify the 
additional experience required for an alternate solution. 

1 Solution . The best solution is the Remote Bridge as the customer requires 
the transparency of the T-R for a portion of the traffic in the network. 
In addition the customer has limited SNA skills where use of a LAN manager 
would be familiar and therefore simpler. There are also no over-riding 
factors to warrant negating their prior experience. Also, the use of LPDA 
on the intermediate link is less of an issue because of the use IDNX CNM 
on the Tl circuits. Finally, the TR-to-TR and TR-to-S/370 requirements are 
both appropriately addressed by the Remote Bridge. 
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Under different conditions a gateway solution might be better than a Remote 
Bridge: 

■ Where the capacity and flow control mechanisms are needed to satisfy 
the through-put requirements (and Ethernet is not an issue) . 

■ Given no other major issues, if the customer has significant experience 
with NetView and views LANs as a network expansion that should be fully 
managed within their current network management system, a combination 
of LAN Manager and NetView provides full coverage. 

Exceptions . In campus type environments, a Local Gateway can be used in 
place of, or in addition to a Remote Bridge. 

The 3172 Interconnet Controller provides gateway channel access to a S/370. 
It connects Ethernet or Token-Ring LANs to S/370 resident TCP/IP or Inter- 
link Business Partner products. This provides the customer fully opera- 
tional communication between DEC network facilities and IBM TCP/IP or 
Interlink Business Partner facilities. 
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SCENARIO #4: REMOTE TP-LINE/LAN CONCENTRATION 

■ Description . The customer has both Token-Ring and communication line re- 
quirements. They plan to install Token-Rings to address data center and 
warehouse needs. They have an existing 3174 network that must be consid- 
ered. In addition, a new business opportunity requires asynchronous dial-up 
access to the S/370. Should they build a network based on bridged Token- 
Rings and 3174s, or a mesh network of 3745 gateways for the Token-Rings and 
3174s. 

■ Overview . The customer has order-billing, inventory management, shipping, 
receiving, and accounting running on multiple S/370 hosts at two data cen- 
ters. The data centers are 30 miles apart. 3270s (located at 17 distrib- 
uted warehouses) access either data center's hosts via multi-drop, 9600bps 
lines. There are also 20 sales offices using the 3174 network (12 are co- 
located with a warehouse). 

The customer uses SNA networking to provide access and NetView to manage 
the remote and local resources. They will implement Token-Ring attached 
PS/2s for the new and enhanced warehouse applications. 

Current network response time is a problem. Both PS/2 and 3174 projections 
indicate a minimum line speed of 56Kbps is required. The ASYNChronous re- 
quirements are less demanding, 1200 to 2400 bps is sufficient. 

Previous network studies did not justify network concentration. However, 
cost projections for the expanded network indicate solid cost savings. A 
workable solution will not require remote concentration and concentration 
will not eliminate the need for local S/370 Token-Ring gateways. However, 
including remote concentration will provide valid savings and may signif- 
icantly alter the selection process. 
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Decision Criteria for additional communications functions: 

■ Network Topology Token rings will be installed in the warehouses and 
data centers. The Token-Rings can be bridged and S/370 access provided 
by 3174 or 3745 gateways. An alternative solution is to connect the 
Token-Rings directly to 3174 or 3745 remote gateways. 

Key considerations are: 

▲ SNA 3174 support for non-warehouse locations 

▲ Dial-up ASYNC support for the new business opportunity 

▲ Multi-host/multi-site connectivity requirements. 

▲ Network concentration 

▲ Response time 

■ Line support . SNA line support requires a 3745. If remote SNA line 
concentration is addressed, local and remote 3745s could be used. 

Dial up ASYNCh support requires either 3174s with ASCII Emulation 
Adapters or a 3745 with NTO(or 3708s). Remote 3174s could be attached 
via bridged rings to channel attached gateways (3174s or 3745s). The 
3174 could also act as the remote Token-Ring gateway attaching via SNA 
links to the 3745 S/370 gateway (load vs response time will be the de- 
ciding factor). A 3174 simultaneously supports ASYNChronous/ASCII 
connections. Additional port for ASYNChronous/ASCII support will in- 
crease the total number of 3174s required. 
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The 3745 supports ASYNChronous terminals via NTO or 3708s. 3708s could 
be co- located with 3745s or installed at remote sites. In either case 
they can be multi-dropped to reduce the total number of 3745 SNA ports 
required. 

■ Cost /function . The unit cost for a remote 3745 is higher than that of 
the other alternatives. However, total network systems cost should be 
about the same when offsetting costs are examined (ie. 
Support/Concentration of Token-Ring, SNA, and ASCII facilities) 

Local 3745 gateways are required for S/370 channel access to multiple 
hosts and networking between sites. 

■ Network Management . The 3745 provides full SNA backbone (and down- 
stream) network management information via NetView and NPM. The remote 
3745 passes data between NetView and the Token-Ring LAN Manager (re- 
quired) in order to provide NetView a more complete picture of the 
network . 

The 3174 provides Token-Ring support for NetView via its integrated Ring 
Error Monitor (REM) facility. ASYNC port status is also provided to 
NetView, however, more detailed line statistics are not available. 

■ Additional Functions . Each solution provides the ability to inter- 
connect host sites. Either via SNA/SDLC communication lines or Token- 
Rings (may require remote bridging). Hosts inter- connection via 
SNA/SDLC would require channel attached 3745s. Host interconnection 
via Token-Rings (bridged or local) would require channel attached 
3174s, or 3745s. Local and/or Remote 3745s can be inter- connected via 
Token-Rings (bridged or local) . In this case the Token-Rings serve as 
3745 to 3745 INN links. 

The 3174 provides multi-host/multi-session attachment of T-R, 
coax/balun and ASYNC port attached devices. 

The 3745 provides multi-link, multi-site mesh networking capabilities 
for ASYNC, BSC, SNA and Token-Ring attached devices. In addition, the 
3745 provides VTAM/NCP based channel, intermediate link and down line 
network pacing, flow control. 

Solution . The solution is Local 3745 gateways for access to multiple hosts 
and remote 3745 gateways for line concentration. The CNM facilities of 
NetView and LAN MANAGER will be used for both local and remote (intermediate 
and down-line) facilities. The combination of remote Token-Ring, 3174 and 
ASYNC support concentrated via the 3745 solution provide a flexible base 
for growth and fully respond to current requirements. 

Under different conditions the other solutions could be appropriate: The 
OS/2 EE gateway could be considered if the I/O loads were lighter because 
it offers downline support for ASYNC and switched SDLC. 

The remote bridge/3174 combination could be selected provided there was no 
requirement for SNA line concentration and: 

■ If the several hundred retailers needed short and occasional access, 
(ie. where a reasonable number of 3174s could handle the random activ- 
ity) 
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If there was a requirement to tie the various warehouses Token-Rings 
together a single logical Token-Ring. 
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SUMMARY .. NETTING IT OUT ! 

1. When the requirements are: 

■ The lowest (unit) cost gateway 

■ Line speeds up to 19.2Kbps 

■ 3270 emulation in an SNA multi-drop environment 

■ The Workstation environment is DOS or 0S2 

THE CHOICE IS THE PERSONAL COMMUNICATION/3270 GATEWAY 

2. When the requirements are: 

■ A low (unit) cost multi-function gateway 

■ Line speeds up to 19.2Kbps 

■ 3270 emulation in an SNA multi-drop environment 

■ The workstation environment is: 

■ DOS migrating to an OS/2 environment (or) 

■ An established 0S2 environment 

THE CHOICE IS THE OS/2 EE GATEWAY 

3. When the requirements are: 
Low to medium unit cost 

S/370 channel attached access to an SNA based host (and/or) 
Line speeds up to 64Kpbs 

S/370 remote access to SNA based host(s) (and/or) 
Enhancement/ expansion of 3174 install base 

THE CHOICE IS .... THE 3174 GATEWAY 

4. When the requirements are: 

■ Low unit cost 

■ S/370 channel access to TCP/IP facilities (or) 
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■ S/370 channel access to INTERLINK Business Partner facilities 
THE CHOICE IS .... THE 3172 (OR 8232) GATEWAY 

When the requirements are: 

Medium Cost Token-Ring interconnection 

Line speeds up to Tl rates 

Workstation access to remote T-R services (and/or) 

Access to S/370 host services via Gateways (and/or) 

Gateway to Gateway interconnection (and/or) 

Protocol independent transport 
THE CHOICE IS THE TOKEN-RING(T-R) BRIDGE 

6. When the requirements are: 

■ Line speeds up to Tl rates 

■ Support for Multiple lines and/or Token-Rings 

■ Channel access to multiple S/370 hosts (and/or) 

■ Remote access to multiple S/370 hosts (and/or) 

■ Concentration of T-R, SNA, BSC, ASYNC facilities (and/or) 
THE CHOICE IS ... THE 3745 GATEWAY 

The summary items shown above account for a large percentage of the selections 
that must be addressed. However, there are potentially hundreds of permutations 
possible and each of them could easily result in a different selection than the 
base case discussed above. For instance; if a 3174 or 3745 was already in place 
at a remote location it could easily cause the selection to differ. Another 
factor that may have significant impact is the cost differential (between sol- 
utions) caused by Modem/DSU-CSU requirements. 

When considering a more complex set of issues the following items should be 
included in the selection process. 

Modems/DSU-CSUs (Speed/ function and cost vary widely) 

Other Network functions provided/required 

Network topology options (impact of concentration, muti-drop etc.) 

Network function (Voice/Data/Image, Tl MUX's) 

Network Management and Automation requirements 

Backup/Recovery/Resynch of Applications 

Network Availability (alternate routes, switched backup etc.) 
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■ Network Stability (growth, change, load etc.) 

■ Network Complexity ( mult i- vendor, number of nodes, overlap ) 

■ System/Network resource utilization/ impact (cycles, memory etc.) 

These are just some of the factors that influence the true cost of a solution. 
Low unit cost can be a real benefit or conceal a much higher overall system cost. 
Likewise, the higher cost of unnecessary facilities can also be a problem. That 
is why it is important to analyze the requirements well enough to avoid inap- 
propriate solutions This effort can be aided by using the tools available, in- 
cluding the HONE tools and SNAP/SHOT. 
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APPENDIX A. OTHER IBM GATEWAY/BRIDGE PRODUCTS 

This section includes information on additional IBM products capable of pro- 
viding T-R gateway or bridge functions. While not included in the main body 
of the document, the products covered in this appendix are capable of providing 
excellent Token-Ring LAN gateway or bridge facilities appropriate to their in- 
tended use. Normally, the AS/400 and ES/9370 both provide application proc- 
essing facilities for end user. The 3172 and 8232 normally provide T-R or 
Ethernet gateway access to Non-SNA based facilities resident on an IBM S/370. 
The 8209 provides interconnection of Token-Ring and Ethernet V2 or 802.3 LANs. 
The products in this section are the IBM: 

3172 Interconnect Controller 

8209 LAN Bridge 

AS400 Intermediate Processor Family 

9370 Intermediate Processor Family 

8232 LAN Channel Station ( 

They covered to the extent that their use as T-R gateway alternatives can be 
appropriately assessed. 
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IBM 3172 INTERCONNECT CONTROLLER 

ENVIRONMENTS 

The 3172 Interconnect Controller provides S/370 channel access to Ethernet, 16/4 
Token-Ring, MAP Version 3.0 Broadband and MAP Version 3.0 Carrierband LANs where 
either TCP/IP or MAP Version 3.0 protocols are used. 

Customers using LANs to connect multivendor environments, or departments with 
workstations using AIX or UNIX require the inter-operability of TCP/IP. The 
3172 provides the S/370 gateway support for high-speed LAN attachment to IBM 
S/370 hosts utilizing: 

■ TCP/IP for MVS 

■ TCP/IP for VM 

■ AIX/370 

■ Interlink Business Partner products 

Equally important; customers using MAP broadband or carrierband LANs to connect 
shop floor operations can benefit from high-speed 3172 connection to System/370 
hosts running IBM OSI/Manufacturing Messaging Services VM. 

The 3172's technology base, performance, configuration flexibility, and multi- 
ple protocol support provides many advantages, including: 

■ Proven, state of the art technology (ie. the 80386 and IBM's Micro Channel 
architecture 

■ Support for up to 4 high speed, concurrent LAN attachments 

■ Incremental growth via connection of 1 to 4 LANs and 1 or 2 System/370 
channels . 

■ Attachment of MAP Version 3.0 LANs, Ethernet and Token-Ring Networks to the 
same 3172 Interconnect Controller. 

The 3172 provides a versatile and competitive LAN gateway facility for customers 
in multi-vendor and/or manufacturing environments. 

OVERVIEW 

The 3172 Interconnect Controller is a high-speed, channel-attached control unit 
optimized for attachment of local area networks to IBM S/370 host processors. 
The use of the 80386 25 MHz microprocessor, a 64-kilobyte cache memory and the 
Micro Channel architecture provides the support necessary to meet the associated 
capacity requirements. 

The IBM 3172 Interconnect Controller: 

■ Provides LAN connectivity to IBM System/370 hosts for: 

IBM Token-Ring Networks - IEEE 802.5 
Ethernet Version 2 and IEEE 802.3 
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MAP Version 3.0 Network - IEEE 802.4 
■ Supports various host protocols/environments: 
IBM TCP/IP for VM 
IBM TCP/IP for MVS 
IBM AIX (TM)/370 
IBM OSI/MMS for MAP Version 3.0 

CONFIGURATION 

HARDWARE: 

The 3172 provides one channel adapter as a standard feature and four feature 
slots for a variety of LAN adapters as optional features. A second channel 
adapter is supported and can be ordered as an optional feature. The base unit 
is comprised of the following basic components: 

System board with RAM and processor 

Diskette drive 

Hard disk 

One channel adapter 

Power supply 

Cabinet with operations panel 

Local Area Network adapters are available as optional features. These may 
be ordered with the 3172 or via MES field installation. There are three 
adapter types which can be installed in any of the four available feature 
slots . 

Note: The MAP Version 3.0 adapters require two feature slots. The maximum 
of four LAN adapters is reduced by one for each MAP Version 3.0 adapter 
installed. 

The four LAN adapters types are: 

■ IBM Interconnect Controller Token-Ring Adapter (#2210) that attaches 
to either a 16 or 4 Mbps Token-Ring Network that conforms to the IEEE 
802.5 architecture. 

■ IBM Interconnect Controller Ethernet Adapter (#2220) that provides at- 
tachment to Ethernet LANs conforming to IEEE 802.3 architecture. Con- 
nection to both "thin" and "thick" Ethernet LANs are supported. 
Attachment cables to the transceiver are not provided by IBM. 

IBM Interconnect Controller MAP 3.0 Broadband Adapter (#2230) that 
provides connection to MAP Version 3.0 protocol LANs and conforms to 
IEEE 802.4 10 Mbps Token Bus architecture. The adapter controller and 
broadband modem are provided as a part of this feature. This feature 
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requires two feature slots in the 3172 Model 001. The attachment ca- 
bling is the responsibility of the user. 

IBM Interconnect Controller MAP 3.0 Carrierband Adapter (#2240) that 
provides connection to MAP Version 3.0 protocol LANs and conforms to 
IEEE 802.4 5 Mbps Token-Bus architecture. The adapter controller and 
carrierband modem are provided as a part of this feature. This feature 
requires two feature slots in the 3172 Model 001. 

■ System/370 Channel Adapter (#2001) that interfaces with IBM's System/370 
Block Multiplexer Channel as if it were a 3088. The channel adapter will 
support speeds up to 4.5 megabytes per second. One channel adapter comes 
standard in the 3172 Model 001. This feature allows a second channel at- 
tachment either on the same channel or a separate channel. 

■ Rack Mounting Assembly (#2500) that allows the 3172 Model 001 to be mounted 
in the 9309 Rack Enclosure Model 002. 

The 3172 enables concurrent attachment of multiple LAN types to the System/370 
for applications using TCP/IP and MAP protocols. 

SOFTWARE 

The IBM 3172 Interconnect Controller connects LANs running the TCP/IP protocol 
to System/370 environments running IBMs TCP/IP products supporting: 

MVS/ESA 

MVS/XA 

MVS/370 

VM/XA SP 

VM/SP HPO 

VM/SP AND AIX/370 

Note: OSI/Manufacturing Messaging Services VM supporting MAP Version 3.0 
is supported by the 3172 Model 001. 

3172 Program Considerations: 

Each 3172 Model 001 requires the IBM Interconnect Controller Program (5601-400), 
or equivalent, which contains all the necessary support to control the data flow 
from a given LAN adapter to a channel adapter (sub-channel) and/or from a 
channel adapter (sub-channel) to a LAN adapter. Multiple LANs can be connected 
to a single sub-channel or multiple sub-channels. A logical connection between 
a given LAN and a sub-channel is permanently established at IPL time. The 
routes are established from a previously loaded configuration. 

A stand-alone configuration utility is included with each IBM Interconnect 
Control Program licensed program. The utility operates with PC-DOS Version 3.3 
or 4.0, or the DOS partition in the OS/2 Operating System. It is used to prepare 
a configuration file on the diskette that is shipped with the Interconnect 
Controller Program. 
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Host Program Considerations 

Each channel -attached IBM host (in order to match the 3172 program configura- 
tion) requires one of the following: 

■ IBM TCP/IP for VM Program (5798-FAL) Version 1.2 

■ IBM TCP/IP for MVS Program (5685-061) Version 1.0 

■ IBM AIX/370 (5713-AFL) Version 1.0 which includes TCP/IP layers 

■ IBM OSI/Manufacturing Messaging Services VM (5684-107). 

Workstation Program Considerations: 

Each IBM Personal Computer or PS/2 workstation communicating with the host via 
the 3172 Interconnect Controller may use one of the following: 

IBM TCP/IP for the Personal System/2 

IBM AIX Personal System/2 TCP/IP 

IBM AIX Access for DOS users. 

IBM X Windows for IBM DOS. 

IBM AIX/RT Version 2.2 

IBM OSI/Manufacturing Message Services for OS/2 

AS/400 TCP/IP Connectivity Utilities (5728-TC1) (provides TCP/IP 
connectivity to a host via Token-Ring or Ethernet Version 2 or IEEE 802.3 
through the IBM 8209 LAN Bridge) 

CONSIDERATIONS 

The 3172 Interconnect Controller provides a specialized set of S/370 gateway 
facilities. The 3172 is the product product of choice in situations requiring 
it's capabilities. However; the 8232 should be considered until the 3172 is 
available. 

■ If the requirement is to attach workstations to S/370 hosts in order to 
access SNA/3270 based applications use one of the other IBM gateway pro- 
ducts. 

Note: The following STATEMENT OF DIRECTION was included in the IBM Computer 
Integrated Manufacturing (CIM) Plant Floor Communications Overview (289-527 
10/24/89) announcement: " VTAM will be enhanced to support access to the 
IEEE 802.4 Token-Bus LAN for the OSI/Communications Subsystem and for SNA 
protocols in MVS and VM environments via the 3172 Interconnect Controller." 

■ If the requirement is to inter-connect dissimilar computing environments, 
TCP/IP and the 3172 provide an excellent solution. 

■ If the requirement involves MAP the 3172 is the best solution. 
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If the need is to interconnect DECnet and SNA facilities the SNS product 
set from the Interlink Business Partner in combination with the 3172 is a 
very cost effective solution. 

If PC Network or MAP 2.1 support is required the 8232 should be selected. 
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THE IBM 8209 LAN BRIDGE 

The IBM 8209 LAN Bridge interconnects an IBM Token-Ring Network with an Ethernet 
Version 2 or IEEE 802.3 local area network. Stations residing on the two dif- 
ferent LANs can communicate across this connection using compatible communi- 
cation protocols such as TCP/IP, OSI, SNA, NETBIOS, or IEEE 802.2. 

ENVIRONMENT 

The 8209 LAN Bridge provides a low cost solution for customers with inter- 
connect requirements in mixed Ethernet, IEEE 802.3 and Token-Ring Network LANs 
environments . 

Customers involved in application areas where Ethernet or IEEE 802.3 LANs are 
widely used will find the 8209 an attractive means of resolving Token-Ring 
interconnect requirements. 

Systems and workstations with compatible protocols such as TCP/IP, OSI, SNA, 
NETBIOS or IEEE 802.2 can communicate across this connection. The 8209 provides 
all conversions required to route information between the dissimilar LANs. 
Token-Ring resident facilities see the 8209 as a bridge to another Token-Ring 
while Ethernet or IEEE 802.3 facilities see it as functionally transparent. 

8209 OVERVIEW 

Description: The IBM 8209 LAN Bridge 

interconnects an IBM Token-Ring Network and an Ethernet or IEEE 802.3 Local Area 
Network. The 8209 provides for transfer of information between Token-Ring 
Network and Ethernet or IEEE 802.3 LAN attached devices. The 8209 performs the 
conversion and format manipulation appropriate to the process. 

The 8209 LAN Bridge: 

■ , Bridges 16/4 Mbps Token-Ring Networks to: 

■ Ethernet Version 2 LANs 
IEEE 802.3 LANs 

■ Supports Ethernet Version 2 or IEEE 802.3 simultaneously 

■ Appears as a Token-Ring bridge to Token-Ring stations 

■ Is functionally transparent to Ethernet/IEEE 802.3 stations 

■ Allows configurations supporting multiple protocols 

■ Is compatible with the IBM LAN Manager program 
The LAN Bridge operates in two different modes : 

■ Mode 1 provides Logical Link Control (IEEE 802.2 LLC Type 1 connectionless) 
emulation. It supports TCP-IP and LLC protocols (ie. SNA, NETBIOS, etc.). 

■ Mode 2 provides MAC (Media Access Control) level bridge support that 
transfers LLC frames without modification. 

Appendix A. OTHER IBM GATEWAY/BRIDGE PRODUCTS 82 



The IBM 8209 LAN Bridge will support a maximum combined total of 2048 stations 
(1024 of which can be Token-Ring stations). 

To correctly operate with the 8209 the interconnected LANs and LAN stations must 
comply with appropriate specification, as indicated below: 

■ IBM Token-Ring Network 

Operational MODE 1 - IEEE 802.5 and 802.2 
Operational MODE 2 - IEEE 802.5 and 802.2 

■ Ethernet 

■ Operational MODE 1 - "The Ethernet: A Local Area Network Data Link Layer 
and Physical Layer Specification Version 2" dated September 1983 and 
issued by Digital Equipment, Intel and Xerox Corporations. 

Operational MODE 2 - IEEE 802.3 and 802.2 

The IBM 8209 LAN Bridge provides the Token-Ring Network LAN Reporting Mechanism, 
Ring Parameter Server, LAN Bridge Server and advanced configuration (via a 
utility program covered later in this section) functions. Acting as a logical 
LAN management agent, it interfaces and is compatible with the IBM LAN Manager 
Versions 1.0 and 2.0. The Lan Manager program allows the customer to change 
8209 LAN Bridge Token-Ring default configuration parameters and to collect 
statistical frame traffic information stored in the 8209. 

Operation: The Ethernet/IEEE 802.3 port 

attaches to either an Ethernet Version 2 or IEEE 802.3 LAN. The 8209 accommo- 
dates these two CSMA/CD LANs through two modes of operation. The operational 
mode is determined by configuration switch settings. With the switches set for 
Automatic Mode Detection, the 8209 examines the data stream and dynamically 
adapts to the proper mode. This permits simultaneous support of both modes of 
operation. However, if the destination address of the Ethernet or IEEE 802.3 
facility is not in the 8209 database, the correct format can not be dynamically 
determined. In which case, the 8209 will perform format conversion based on 
the setting of the configuration switch. 

■ MODE 1 is used to bridge Token-Ring to Ethernet Version 2 LANs. 

■ Above the physical layer, Token-Ring and Ethernet Version 2 differ in 
Media Access Control (MAC) and user Datagram services. 

The Token-Ring MAC layer complies with IEEE 802.5 while Ethernet uses 
CSMA/CD and does not specify an 802.5 Logical Link Control interface. 

■ Token-Ring offers both Connectionless (Type 1) and Connection Oriented 
(Type 2) Logical Link Control (LLC) services. (The workstations must 
support LLC) 

■ There is no Ethernet Version 2 LLC equivalent function. The 8209 LAN 
Bridge handles this difference in MODE 1. 

■ TCP/IP exchanges between stations on the different LANs would use op- 
erational MODE 1. 
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■ MODE 2 interconnects Token-Ring and IEEE 802.3 LANs. 

Provides IEEE 802.5 (Token-Ring) to/ from IEEE 802.3 MAC level frame 
conversion 

■ Protocol layers above the MAC level are transparent to the 8209 LAN 
Bridge and are passed through without modification 

SNA, NETBIOS, OSI, or IEEE 802.2 sessions between stations on the dif- 
ferent LANs would use MODE 2 

The 8209 LAN Bridge maintains two data bases 

■ The first contains addresses for Ethernet/IEEE 802.3 stations (static and 
dynamic entries) 

■ The other contains Token-Ring station addresses and routing information 
(dynamic entries) 

Note: Static entries differ from dynamic entries in that they are set up 
in non-volatile RAM. Dynamic entries are created as part of the 8209* s 
"learning process" and are lost when power is removed. 

After power on initialization, the Ethernet/IEEE 802.3 data base is initialized 
with static entries. The 8209 enters the learning state, listens to all frames 
on the Ethernet or IEEE 802.3 port and saves each unique source address in the 
data base. 

While in this state, the 8209 LAN Bridge will not forward any frames. After a 
few seconds the bridge leaves the learning state and begins normal operations. 
During normal operations the 8209 LAN Bridge updates the data base when a new 
source address is detected on an Ethernet or IEEE 802.3 frame. 

The Token-Ring data base is dynamically built during normal operations. Entries 
will be added to the Token-Ring data base only for stations with frames that 
are forwarded on the Ethernet/IEEE 802.3 port. 

The 8209 LAN Bridge provides for a combined total of 2048 data base entries: 

■ The number of Token-Ring entries in the data base range from 1 to 1024 

■ The number of entries in the Ethernet/IEEE 802.3 data base ranges from 1 
to 2047 

Note: An Aging Timer will determine how long inactive Dynamic Entries will 
remain in the data base. Static data base entries are not subject to re- 
moval by the Aging Timer. 

Configurable filters are used to reduce passing unnecessary traffic. For ex- 
ample, filters may be set up so that only TCP/IP traffic is forwarded to either 
port. Filtering improves performance and ensures no degradation due to unnec- 
essary traffic. 

CONFIGURATION 

The 8209 LAN Bridge is physically packaged in a table top configuration suitable 
for stacking or shelf mounting in industry standard racks. 
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The 8209 LAN Bridge is functionally packaged: 

■ The base unit contains the Token-Ring facilities 

■ Feature #6035 provides the Ethernet/IEEE 802.3 function and also contains 
the configuration switches (#6035 is mandatory) and 

In most environments LAN Management functions and configuration customization 
are not required to install the 8209 LAN Bridge. The 8209 configuration (as 
shipped) adapts to the installed environment. 

The 8209 LAN Bridge is shipped with configuration variables set as follows: 

Operational Mode = Automatic Mode Selection Enabled with Mode 1 Priority 
Operation 

Token-Ring Speed = 4 Mbps with Early Token Release Disabled 

Token-Ring LAN Number = Zero 

Ethernet/IEEE 802.3 LAN Number = 4080 

Initial Bridge Number = Zero 

To accommodate additional and more complex environments the following facili- 
ties are provided: 

■ Hardware configuration switches 

■ Token-Ring Network LAN Bridge Server functions 

■ An 8209 configuration utility program. 

The following options can be selected by hardware switches: 

■ Enable/Disable Automatic Mode Selection 

■ Mode 1/Mode 2 Priority Operation 

■ 4 or 16 Mbps Token-Ring 

■ Initial Bridge Number (0, 1, 2 or 3) 

Ethernet/IEEE 802.3 LAN Number 

Note: The Automatic Mode Selection function allows the 8209 to support 
both Ethernet Version 2 and IEEE 802.3 (Mode 1 and Mode 2) at the same 
time. The determination for mode of operation is done dynamically. 

The 8209 provides the following management functions: 

■ Token-Ring Network LAN Reporting Mechanism 

■ Ring Parameter Server 

■ LAN Bridge Server functions 

The 8209, acting as a logical LAN management agent on the Token-Ring Network, 
will: 

■ Keep and report statistical frame traffic information 
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■ Accept and respond to requests for Bridge and Route status 

■ Accept and respond to commands which change Bridge configuration parame- 
ters. 

The controlling LAN MANAGER can set/reset these configuration parameters: 

■ Notification interval for performance statistics 

■ Bridge internal status 

■ Hop count 

■ Ring number 

■ Bridge number 

The LAN Manager, installed on a Token-Ring station, sets up a link to the 8209 
LAN Bridge in order to communicate these management functions . The 8209 LAN 
Bridge provides management information to the LAN Manager for only the 
Ethernet/IEEE 802.3 segment to which it is attached. 

A utility program is shipped with the 8209. This utility runs under either PC 
DOS or OS/2 in an IBM PC or PS/2. The utility allows the customer to set up 
filters, static data base entries, ring numbers, bridge number, and timers which 
control operation of the 8209 LAN Bridge. The PC or PS/2 communicates the 
configuration parameters to the 8209 over the Token-Ring. The 8209 Utility 
Program allows the customer to examine and modify the following parameters: 

Spanning Tree Parameters 

Operational Mode 

Enable/Disable Early Token Release 

Filter Definitions 

Ethernet/IEEE 802.3 Static Database Entries 

Ethernet/IEEE 802.3 Port Statistics 

Bridge Number 

Token -Ring LAN Number 

Ethernet/IEEE 802.3 LAN Number 

In addition to configuration, the 8209 Utility Program provides a means to 
collect Ethernet/IEEE 802.3 port statistics which are gathered by the 8209. 

CONSIDERATIONS 

The 8209 is designed to address the specific function of Token-Ring connection 
to/from Ethernet Version 2 or IEEE 802.3 LANs. 

The 8209 can easily be used in combination with other IBM Token-Ring bridge and 
gateway products in order to tailor an optimum solution for a customers re- 
quirements. 
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8232 LAN CHANNEL STATION 

In addition to our SNA gateway products, IBM also offers the 8323, intended for 
specialized, non-SNA connectivity requirements. The 8232, provides 
connectivity for TCP/IP and MAP environments, for DECnet via the Interlink 
Business Partner, and also provides a PC link into VM Pass-Through networks. 

Note: The 8232 LAN Channel Station will be performs functions similar to the 
IBM 3172. It should be considered when installation is required before avail- 
ability of a 3172 or when MAP 2.1 or PC Network is required. 

ENVIRONMENTS 

The 8232 answers customer requirements in two major areas: 

1. Multi-Vendor Communications 

Many customers need to have their mixed vendor network facilities function 
transparently, from the end users point of view. End users, in this envi- 
ronment, need not know where an application is running, nor move to another 
workstation to access an application on another application processor's 
network. To achieve this level of operation, many customers are imple- 
menting multi-vendor communications via TCP/IP or Interlink Business Part- 
ner products. 

■ TCP/IP 

TCP/IP is a set of protocols which have been implemented across a wide 
variety of computing environments, from PCs to mainframes. These pro- 
tocols, developed by the US government, allow machines of different type 
and architecture to send files and access applications across the net- 
work. IBM provides a range of software for the S/370 (MVS, VM, and 
AIX), PS/2, PC, and RT to support TCP/IP. 

■ Interlink 

Similar requirements exist in mixed IBM/DEC environments. The SNS 
product set from the Interlink Business Partner addresses this re- 
quirement by providing a powerful DECnet/SNA gateway facility. 

The implementation provides users a high-speed link between IBM S/370s 
and systems operating on a DECnet network. 

In these environments the 8232 also provides direct bridging of Token-Ring 
and Ethernet LANs . 

2. Manufacturing Automation Protocol 

MAP is a protocol which was developed by a number of large manufacturing 
customers to help simplify the task of plant automation. MAP allows com- 
puter to computer communication for control of machine tools, and other shop 
floor hardware. 

The 8232 allows a VM host, configured with appropriate software, to commu- 
nicate with a network of shop floor controllers. Since the 8232 is directly 
connected to the 370 -channel, throughput and response are excellent. 
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OVERVIEW 

The IBM 8232 LAN Channel Station provides data transfer/connection services 
between TCP/IP application facilities on a S/370 and LAN attached workstations 
also using TCP/IP. The 8232 provides channel access to the S/370 using VM or 
MVS channel I/O. 

The 8232 attaches an: 

■ IBM Token-Ring Network 

■ IBM PC Network Broadband 

■ Ethernet Network 

All running the Transmission Control Protocol- Internet Protocol (TCP/IP) 
to an IBM 308X, 3090 ES/3090* 4361, 4381 or 937X host processor. 

The 8232 also provides for attachment to the S/370 sub-channel of a Manufac- 
turing Automation Protocol (MAP) Version 2.1 Network, Advanced Executive 
Interactive/370 (AIX/370)* workstations, and IBM VM/Pass -through PVME 
(program-to-program communication between PC workstation and VM System) . 

The 8232 can also provide connectivity between a DECnet Ethernet environment 
and a S/370 using the Interlink SNS/SNA or SNS/9370 product set. Model 001 of 
the 8232 LAN Channel Station provides connectivity between one S/370 sub-channel 
and up to two LANs, and Model 002 provides connectivity between two S/370 sub- 
channels and up to four LANs. 

The IBM Industrial Computer, 7532-266 while separately priced is a necessary 
component of the 8232 system, and is shipped together with the 8232. 

CONFIGURATION 

The IBM 8232 LAN Channel Station consists of a relay rack containing power 
supplies, an IBM Industrial Computer 7532-266 prepackaged with covers, power 
cable keyboard, 1.2 MB high Density diskette drive, 512 Kb of RAM, channel 
drivers and connectors, and a Color/Graphics Monitor Adapter. The customer 
supplies a display monitor for hardware diagnostics, software installation, and 
the appropriate LAN Adapters . 

The 8232 Model 001 consists of one IBM Industrial Computer 7532-266, space for 
two IBM Token-Ring Network adapters, or two PC Network Broadband adapters, or 
two Ethernet Network adapters, or one INI MP-500 MAP Interface Adapter and can 
connect to one host channel/sub-channel. Model 002 connectivity is twice that 
of a Model 001 (it contains two units). 

The IBM 8232 provides access to a S/370 sub-channel on IBM host processors 
(308X, 3090 ES/3090, 4361, 4381, 937X) for client workstations attached to a 
LAN. The host side of the IBM 8232 is capable of operating Data Channel In- 
terrupt (DCI) mode or in datastreaming mode. With any of the supported programs 
installed, the IBM 8232 LAN Channel Station appears as an IBM 3088 Control Unit 
to the host processor. 

The IBM 8232, utilizing the IBM 8232 LAN Channel Support Program, 5601-232, (See 
Programming Announcement dated September 20, 1988), operates with TCP/IP pro- 
tocols on three LANs, the IBM Token-Ring Network, the IBM PC Network Broadband, 
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and the Ethernet Network. Under these conditions, the IBM host may be operating 
one of the following: 

■ Transmission Control Protocol- Internet Protocol (TCP/IP) for VM program 
offering (5798-FAL) which supports VM/SP, VM/SP HPO, and VM/XA SP. 

See Announcement Letter 288-396. 

■ AIX/370, Program Product (5713-AFL), which also includes the TCP/IP Proto- 
col Layers. 

NOTE: This combination does not operate on the PC Network Broadband and is 
not supported. 

See Programming Announcement Letter 288-130 dated March 15, 1988 

The Interlink product set, referred to as the SNS/SNA Gateway (TM) Family, 
consists of several products: 

■ SNS/Connect - the software platform that permits inter-operability between 
DECnet networks and a host IBM S/370. 

■ SNS/Path - extends the inter-operability to other 370s in the SNA network. 

■ SNS/NETconnect - providing NetView linkages into DECnet. 

■ Additional SNS products for terminal emulation, LU 6.2, and electronic mail 
inter-operability. 

When the IBM 8232 is attached to a MAP Network Version 2.1 it must be operating 
the supported Program Offering, IBM MAP LAN Channel Support Program, 5798-FBF, 
and the IBM Host must be operating the Program Offering, the MAP V2.1 Protocol 
- VM Support., 5798-FBG. 

When the IBM 8232 LAN Channel Station is used to connect the IBM Token-Ring 
Network, or PC Network Broadband into an IBM VM/Pass-through Network, it must 
be operating the Programming RPQ, the IBM VM/ Pass -Through PC Connect Facility 
8232 Communication Program (PVM/PC) Version 1.0, (5799-PGB) PRPQ 

CONSIDERATIONS 

The 8232 is targeted at very specific situations, the considerations are fairly 
straight- forward. The 8232 provides an excellent solution and should be con- 
sidered until the 3172 is available. 

■ If the requirement is to attach of workstations to S/370 hosts in order to 
access SNA/3270 based applications, use one of the other IBM gateway pro- 
ducts . 

■ If the requirement is to inter-connect dissimilar computing environments, 
and TCP/IP can be used the 8232 is an excellent solution. 

■ If the requirement involves MAP, the 8232 is currently the only IBM product 
which allows MAP networks to access S/370 hosts. 

■ If the need is to interconnect DECnet and SNA facilities then the SNS 
product set from the Interlink Business Partner provides a powerful 
DECnet/SNA gateway function. 
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In the environments for which it is designed, the 8232 provides a very cost 
effective solution. 
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ES/9370 PROCESSOR 

In addition to dedicated Token-Ring bridge/gateway products, IBM also offers 
application processors that provide complementary T-R gateway facilities. An 
IBM ES/9370 is an excellent example of a S/370 based system providing such fa- 
cilities . 

ENVIRONMENT 

In the ES/9370 LAN environment there are a number of Token-Ring connectivity 
and support options available. 

■ The ES/9370 supports two types of LANs: 

Token-Ring LAN (IEEE 802.5) at 4Mbps 

Ethernet LAN(IEEE 802.3) at 10 Mbps 

Note: Many factors, in addition to rated speed, determine throughput. 
For instance, it is not out of the ordinary to encounter situations 
where 4Mbps T-R throughput exceeds that of a lOMpbs Ethernet LAN. Refer 
to "LAN Performance Update: 9370 to 9370 via Token-Ring and Ethernet, 
ZZ20-58733-00" for a better understanding of the factors involved. 

■ The ES/9370 supports multiple connections to the same Local Area network. 

■ The ES/9370 supports connections to multiple Local Area Networks. 

■ The ES/9370 Token-Ring Subsystem controller (6034) can be shared between 
different ES/9370 subsystems: 

VTAM 

TSAF 

TCP/IP 

■ An ES/9370 IEC 802.3 Subsystem controller (#6035) CANNOT be shared between 
different communication subsystems. 

OVERVIEW 

The ES/9370 is a family of intermediate processors based on the S/370 archi- 
tecture. They run conventional S/370 bases applications and operating systems. 
Compact design and extensive connectivity allow it to fit into almost any de- 
partmental or distributed environment. It brings to these environments, not 
only application processing but the ability to connect to other S/370 based 
processors. An important aspect of its connectivity is the ability to provide 
T-R gateway services. 

The ES/9370 processor family supports the major operating systems important to 
our customers : 

■ VM/SP 

■ VM/IS 
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VSE/SP 

DPPX/370 

MUMPS (under VM) 

IX/370 (under VM) 

AIX/370 (under VM) 

MVS/SP (limited integrated adapter support in this environment) 

Note: The wide range of operating system environments supported by the 
ES/9370 provides an appropriate platform for almost any requirement. 

Currently available processors are: 

■ 9373 Model 25 

■ 9373 Model 30 

■ 9375 Model 50 

■ 9377 Model 80 

■ 9377 Model 90 

Previously available processors, upgradable to newer models are: 

■ 9373 Model 20 
9375 Model 40 

■ 9375 Model 60 

ES/9370 processors offer a full S/370 instruction set, 16 general registers, 
and the Virtual Memory capability of the S/370 architecture. 

ES/9370 processors provide a variety of I/O controllers/adapters, two types of 
DASD and two types of tape units. They are all rack mountable in 9309 enclo- 
sures . 

All integrated I/O is compatible with the S/370 channel I/O structure. Block 
Multiplexer Channels are also available; providing connectivity for most S/370 
channel attached devices. 

The primary difference between models is individual processor power. This 
manifests itself in the number of users supported by a specific processor model 
(based on the system/application software in use). In addition, the number of 
I/O ports available varies by model (ie. the amount of DASD, I/O channels and 
I/O subsystems is model dependent) . 

ES/9370 LOCAL AREA NETWORK CONNECTIVITY 

ES/9370 Local Area Network hardware connectivity options for downstream support 
include: 
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■ Direct: The ES/9370 provides the application and gateway services for di- 
rectly attached LANs. The ES/9370 supports two types of direct attached 
LANS : 

■ The IBM Token-Ring connected via its IBM Token-Ring Subsystem Control- 
ler 

■ Ethernet connected via its IEEE 802.3 LAN Subsystem Controller 

■ Indirect: The ES/9370 uses a secondary downstream LAN gateway to provide 
connection to its services. The indirect, downstream gateways options are 
one of the following: 

3745/3725/3720 with a Token-Ring Interface Coupler (TIC) 

3174 with a Token-Ring Adapter (TRA) 

AS/400 with a Token-Ring Adapter (TRA) 

■ PS/2 (or PC) with a Token-Ring adapter card and one of the following: 

▲ OS/2 EE gateway program facilities 

▲ PC/3270 gateway program facilities 

EXAMPLE: Connections might be provided via a channel attached 3745 
model 170 gateway, or via a remote 3745 model 130 gateway, connected 
in turn to a channel attached 3745 model 70. 

Note: The attached LANs may also be networks of LANs, inter- connected via 
bridges (local and/or remote) or other facilities, such as the IBM 8209. 

ES/9370 LOCAL AREA NETWORK SOFTWARE SUPPORT 

VTAM Based Token-Ring Support options include: 

■ VM/VTAM V3.1.2 

VSE/VTAM V3.2 

Note: Both provide connectivity for a Token-Ring network via the ES/9370 
Token-Ring Subsystem Controller (#6034) . 

VTAM Workstation and Host support: 

■ Workstations on the T-R are defined as a PU 2.0, switched node types to 
ACF/VTAM. For example; a PS/2 with the appropriate Token-Ring card and 
3270 emulation program facility would be handled, by VTAM, as a 3270 dial-up 
connection to the ES/3790. 

■ VTAM also provides cross-domain connectivity downstream, Token-Ring at- 
tached devices via dedicated (leased) line connections to other VTAM based 
S/370s. In this case the ES/9370/VTAM is defined as a PU 5 to the other 
S/370s, enabling host to host communication. 

■ To ES/9370/VTAM the Token-Ring Subsystem is a locally attached controller 
with four contiguous sub-channel addresses. The CETI (Continuously Exe- 
cuting Transfer Interface) protocol is used to handle communications be- 
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tween VTAM and the Token-Ring. Up to three CETI Groups can be supported 
by the ES/9370 Token-Ring Subsystem. 

Note: A major benefit of using the CETI is enhanced throughput. This is 
done by reducing the number of channel commands and interrupts required to 
pass data across the I/O channel. 

VM/TSAF provides the capability for a TSAF (Transparent Services Access Facil- 
ity) virtual machine to reside in each VM processor. This allows applications 
(servers) transparent access to or from other TSAF connected VM processors. 
Up to 8 VM processors can be connected in this way. There are four connections 
possible: 

■ ES/9370 BSC Teleprocessing link. 

■ ES/9370 SNA Teleprocessing link 

■ ES/9370 Token-Ring Subsystem Controller 

■ ES/9370 IEEE 802.3 LAN Subsystem Controller 

Note: Other non-VM processors or devices may also be connected to the 
Token-Ring or Ethernet networks, but they would be unable to communicate 
with the VM/TSAF virtual machines. 

Note: Although VM-TSAF can connect to a Token-Ring and an Ethernet network, 
no gateway function between the Local Area Networks is provided. 

VM/TCP/IP (Transmission Control Protocol- Internet Protocol) is a US Department 
of Defense communications standard. The IBM program offering, TCP/IP for VM 
(5798-FAL), supports the: 

■ ES/9370 Token-Ring Subsystem Controller 

■ ES/9370 Ethernet LAN Subsystem Controller 
Release 2 of TCP/IP for VM supports: 

■ An ES/9370 Multi-protocol Telecommunications Adapter using SDLC 

■ An X.25 Subsystem 

Note: With Release 2 of TCP/IP for VM it is now possible for a TCP/IP based 
ES/9370 to participate in a wide area networks. 

Note: Although TCP/IP for VM can connect to both a Token-Ring and an 
Ethernet LAN, gateway/bridge support between the two LANS is not provided. 

CONSIDERATIONS 

The ES/9370 is especially strong where S/370 intermediate class processing is 
required along with ancillary, LAN gateway facilities. Its extensive 
connectivity relative to Token-Ring and Ethernet requirements is second to none. 
This, coupled with the broad set of operating support it provides makes it an 
excellent candidate for LAN gateway solutions. 

The major consideration remaining is that of aggregate throughput requirements. 
If extensive application processing is already taking place on a given ES/9370, 
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the addition of a LAN gateway workload could impact response beyond acceptable 
limits. Therefore; it is crucial to user satisfaction to properly assess the 
impact of the LAN gateway function and size the ES/9370 accordingly. 
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AS/400 PROCESSOR 

The AS/400 intermediate level processor is another of IBM's family of Token-Ring 
gateway products. Like the ES/9370, the AS/400 is primarily an application 
processor. As such, it provides Token-Ring gateway facilities that are com- 
plementary to its application processing function. 

ENVIRONMENT 

OS/400 is the singular operating, system facility of the AS/400. The OS/400 
operating system provides all of the Advanced Peer to Peer Networking (APPN) 
facilities needed to support the Token-Ring and communicate with: 

■ Other AS/400s via APPN 

■ S/36s via APPN or LEN/APPC 
S/38s via LEN/APPC 

■ S/370s via VTAM/LEN/APPC 

Note: A utility package is available for specialized S/370 communications 
requirements. The AS/400 Communications Utilities 5728-CM1 provides Remote 
Job Entry Facility (RJEF) and RSCS/PROFSA bridge support. 

The AS/400 Token-Ring provides support for: 

■ 1 Token-Ring adapter on the 9404-B10 (4Mbps) 

■ 2 Token-Ring adapters on the 9404-B20 (4Mbps) 

■ 2 Token-Ring adapters on the 9406 (4Mbps) 

■ Up to 128 devices per adapter on the 9404-A11 models 

■ Up to 256 devices per adapter on the 9406-A11 models 

OVERVIEW 

The AS/400 is a family of intermediate processors based on a unique modular 
architecture. The AS/400 uses the OS/400 operating system to provides new and 
exclusive capabilities while providing migration support for predecessor pro- 
ducts. This allows for the growth needed in today's environment while pro- 
tecting the investment in prior application development. The application 
programs announced with the AS/400 provide solutions for almost any set of user 
requirements. An important part of its connectivity is support of the Token- 
Ring and the 3270 family of products. 

There are nine models (BIO through B70) of the AS/400 available, each offering 
different capacity ranges: 

■ Processing power 

■ Main storage, up to 96 MBytes 

■ Disk storage, up to 38.4 GBytes 
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■ Workstations/Terminals supported, up to 800 

■ Communication lines, up to 48. 

The AS/400 provides support for various protocols via integrated communication 
controllers and multi-protocol line adapters: 

■ ASYNC 
BSC 

■ SDLC 

X.25 

Interfaces provided for ASYNC, BSC, SDLC and X.25 support are V.24, V.35 
and X.21. Maximum line capacity is 64 KBPS. The AS/400 supports autodial 
V.25bis for switched connections. 

■ Token-Ring (4Mbps) 

The AS/400 can be in session with up to 256 devices (128 on the 9404) on 
each Token-Ring Network adapter. The 9404-B10 attaches one Token-Ring 
adapter, the 9404-B20 and the 9406 (all models) attach up to two Token-Ring 
adapters . 

■ TCP/IP 

AS/400 TCP/IP attaches via the Token-Ring and the 8209 LAN Bridge to 
Ethernet Version 2 and IEEE 802.3 LANs. 

SNA Support 

The AS/400 provides SNA communications via the following connection types: 

■ SDLC private (leased) and switched connections 

■ X.25 network switched or private (leased) Virtual Circuits 

■ IBM Token-Ring Network connections. 

Connections between AS/400 and System/370 support the following session types: 

■ LU Type for: 

Host Command Facility (HCF) to Distributed Host Command Facility (DHCF) 

NetView Distribution Manager to AS/400 Distributed Node Executive 
(DSNX) 

User program-to-program communications with CICS or IMS, using the SNA 
Upline Facility (SNUF) 

RSCS/PROFS Bridge which connects to RSCS and MVS/NJE 

User application program communications with 3600, 4600 and 4700 Fi- 
nance and Retail systems 

■ LU Type 1 for: 
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Remote Job Entry to Power/VSE, JES2 and JES3 
IBM 3270 SCS Printer Emulation 

■ LU Type 2 for: 

IBM 3270 Display Station Emulation 

■ IBM 3270 User Application Program Interface 

■ LU Type 3 for IBM 3270 DCS Printer Emulation 

■ LU Type 6.2 for: 

■ User-written APPC programs communicating with CICS 
SNA Distribution Services with DISOSS/370 

DDM (Distributed Data Management) with CICS/OS/VS. 

The only session type used between Type 2.1 nodes is the LU 6.2 session. Com- 
munications Facilities provided by LU6.2 sessions include: 

User program-to-program communications 

IBM 5250 Display Station Passthrough 

SNA Distribution Services, used by Office/400 and Object Distribution Fa- 
cility 

Distributed Data Management (DDM) 

File Transfer Support. 

Non-SNA protocols 

The AS/400 provides the following BSC support: 

■ 3270 Device Emulation 

■ Remote Job Entry Facility 

■ RSCS/PROFS Bridge to RSCS 

■ BSCEL 

The AS/400 provides the following ASYNC support: 

■ Communication with ASYNChronous/ASCII (A/A) based Hosts 

■ Communication with A/A based devices such as PCs, plotters, etc. 

■ Interactive Terminal Facility 

■ File transfer. 

The AS/400 provides the following TCP/IP support: 

■ File Transfer Protocol (FTP) 

■ Simple Mail Transfer Protocol (SMTP) 
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■ Program to program communications for TCP and User Datagram Protocol (UDP) 

APPN Used with X.25 

X.25 provides any-to-any connectivity. In some respects, APPN intermediate 
routing becomes redundant in an X.25 network environment. However, APPN pro- 
vides some definite benefits when used in conjunction with X.25: 

■ Automatic configuration and activation of all peer devices in the network. 

■ Multiple location names (defined at local nodes only) and automatic searches 
(by remote nodes) when a session is requested for a particular location 
name. 

■ Intermediate routing through a host to another APPN network. 

■ Transmission priority for better performance and classification of network 
traffic. 

The following is an example of the benefits resulting from the combination of 
APPN and X.25. 

X.25 performs the intermediate routing function therefore; all nodes on any one 
of the X.25 networks may be end nodes without CP-CP sessions. With no CP-CP 
sessions, the X.25 virtual circuits can be switched and auto disconnect used. 

APPN Used with Token-Ring 

The Token-Ring LAN physical interface is fully supported between IBM AS/400 
systems (definable in an AS/400 line description). IBM AS/400s, S/36s, PS/2, 
PCs can be defined as both nodes in an APPN network and stations in a Token-Ring 

LAN . 

An advantage of using the T-R with APPN is that the benefits of APPN are provided 
over a bandwidth of 190Kbps. Furthermore, as with X.25, since APPN need not 
perform intermediate routing between non-adjacent nodes (the T-R performs the 
any-to-any routing), the benefits of APPN (as for X.25) are available without 
the overhead associated with APPN intermediate routing. 

APPN can provide a bridge between two or more LAN networks. For example, T-R 
LANs could be linked together by interconnecting AS/400/APPN systems residing 
on each T-R LAN. The stations on the LAN can be PS/2s with PC Support or APPC/PC 
along with the AS/400s. This way, APPN and T-R LAN are effectively combined. 
In addition, the remote network inter-connecting the AS/400s could be replaced 
by a T-R network (bridged or local) . 

AS/400 PC Support 

AS/400 PC Support is an application that allows PS/2s to communicate with 
AS/400s functioning as a LAN server. A number of PS/2 user services are pro- 
vided, including: 

■ Shared folders (PS/2 file services) 

■ Virtual printers (PS/2 printer services) 

■ Messaging (AS/400 and PS/2 users) 
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■ Workstation functions (emulation) 

■ File transfer and data conversion (PS/2 to/ from the AS/400) 

■ Organizer, a single menu interface to S/400 and PS/2 facilities 

PC LAN Program VI. 3 and AS/400 PC Support Concurrency 

Token-Ring LAN installations may involve PS/2s requiring access both to PC LAN 
Program VI. 3 services and AS/400s PC Support facilities. It is possible to meet 
this need, within certain limits. Concurrent support can be provided by running 
AS/400 PC Support and PC LAN Program VI. 3 together. An important consideration 
is that that only the base services mode of PC LAN Program VI. 3 may be used. 

CONSIDERATIONS 

The AS/400 is especially strong where APPN wide area networking facilities are 
required along with ancillary T-R LAN gateway facilities. Its extensive ap- 
plication base coupled with its APPN capabilities it an excellent candidate for 
T-R LAN gateway solutions. 

As with the ES/9370, a major consideration is that of aggregate throughput. 
If extensive application processing is already taking place on a given AS/400, 
the addition of T-R LAN gateway workloads could have an unacceptable impact. 
Therefore; it is essential to user satisfaction that the impact of adding 
gateway functions to application processing loads be assessed. 
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APPENDIX B. TOKEN-RING GATEWAYS/BRIDGES CROSS REFERENCE CHARTS 

This section contains a set of "Product Positioning Quick Reference Charts". 
These charts should be used to cross-reference product capabilities against the 
itemized criteria. These charts may be copied and carried as a pocket 
reference/reminder . 
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PRODUCT 



POSITIONING 



Quick Reference Chart - 1 



PRODUCT SELECTION WORKSHEET 



T-R BRIDGE/GATEWAY PRODUCTS 



SELECTION 
-CRITERIA 



DOS 
G-WAY 



0S/2EE 
G-WAY 



REMOTE 
BRIDGE 



3174 



3745 



3172/ 
8232 



GENERAL CHARACTERISTICS 

16-M Token-Ring Speed Support 
S/370 Channel Attachments 
Remote Link(s) to S/370 
Networking Support Level 
T-R LAN adapters/Gateway 
MAX WSs attachable/G'way 
PUs seen on link/Remote-GW 
PUs Polled on link/Remote-GW 



YES 
NONE 
1 
MULTI- 

2 
256 

1 



YES 
NONE 
1 
MULTI- 

2 
256 

1 

1 



YES 
NONE 
1 
CASCAD 
1 
(1) 
(1) 
(1) 



YES 

1 
1-3 
MULTI- 

1 
250 
1/WS 
1(2) 



YES 
16 



YES/NO 

2 



8/TG(3) NONE 



MESH 

2-8 

9999 

1 

1 



LOCAL 
1-4 



1 

(1) Depends on the Gateway the Bridged T-R uses for S/370 access 

(2) 3174 PU Group Poll enhancement used for initial WS contact 

(3) TG refers to 3745/NCP Transmission Groups 

S/370 Gateway required/R Remote | (1) | (1) | (2-3-4) (1) | (1) | — 
(1) 3745/Comm Ports (2) 3745/T-R (3) 3174/T-R (4) 8232/T-R 

Host-End Software Required | (1) | (1) |(l-4) |(l-2) | (1) |(3-4) 
(1) VTAM/NCP (2) VTAM ONLY (3) TCP/IP (4) INTER-LINK 



CENTRAL SITE CNM ENABLING 

R.E.M(l) Alerts to NetView NO NO YES YES NO NO 

Pass-Thru LM alerts to NETV'W YES YES YES YES YES NO 

Pass-Thru NV commands to LM YES YES YES YES YES NO 

Intermediate Link LPDA YES YES NO YES YES 

Downstream Link LPDA NO NO — NO YES 

Remote Link Trace/Stats NO NO — NO YES 

Intermediate Link Trace/Stats 2 2 3 — 3 

(1) Ring Error Monitor 

(2) Via VTAM/NCP (3) Limited Collect 1 n/none transmitted to central site 



PRICE/PERFORMANCE ESTIMATES 
Channel Attached G'way 
Unit Cost 

Response (local LAN) 
WS Service Capacity 
Impact of moves/changes 
Link Attached G* way/Bridge 
Unit Cost 

Response (remote LAN) 
WS Service Capacity 

9.6 to 19.2Kbps 

56Kbps 

Tl 














— 


— 


— 


LO-MED 

SUBSEC 

MED-HI 

HI 


MED-HI 

SUBSEC 

HI-VHI 

LO 


LO 
SUBSEC 
MED 
HI 


V-LO 
SEC 


LO 
SEC 


MED 
SUBSEC 


MED 
SEC 


HI-VHI 
SUBSEC 


— 


LO 


LO 
MED 


LO 

MED-HI 

HI 


LO 
MED 


LO 
MED-HI 
HI-VHI 


— 



Abbreviations: (T-R) Token-Ring 
(GW) Gateway (LM) LAN MANAGER 



(WS) Workstation 
(NV) NetView 



(RB) Remote Bridge 
(CA) Channel Adapter 
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PRODUCT 



POSITIONING 



Quick Reference Chart - 2 



PRODUCT SELECTION WORKSHEET 



T-R BRIDGE/GATEWAY PRODUCTS 



SELECTION 
-CRITERIA 



DOS 
G-WAY 



OS/2EE 
G-WAY 



REMOTE 
BRIDGE 



3174 



3745 



3172/ 
8232 



REMOTE G*WAY/RB CONNECTIVITY 
UP-STREAM COMM. SUPPORT: 
SNA 
PU2.0 

PU2.HNT2.1) 
PU4 

X.25(as T-R G'way link) 
T-R 

Source Rout 'g( 802. 5) RB-RB 
Max Line Speed T-R to SNA 

(in Kbps) T-R to X.25 
Configurable as: 

Dial-up (Switched) 

Multi-Drop 

Point-to-point 

Cascaded 

Mesh (Backbone) 
DOWN-STREAM COMM. SUPPORT: 
PU2.0 

PU2.KNT2.1) 
SDLC 
LU6.2 

ASYNCh/ASCII 
TCP/IP 
X.25 

Token-Ring 
Ethernet 
MAP 

(1) The T-R and Remote Bridge pass the 

(2) PU2.0 Migration Mode (3) FDX at 1 



YES 
YES 
NO 

NO 
YES 

19.2 



YES 

YES 

YES 

NO 

NO 



YES 
YES 
NO 

YES 
YES 

19.2 
64. 

YES 

YES 

YES 

NO 

NO 



n.a 

n.a 

TR-TR 



YES 
1344. 



NO 

NO 

YES 

YES 

NO 



YES 
YES 
NO 

NO 
YES 

64. 



YES 

YES 

YES 

NO 

NO 



YES 
YES 
LEN 
YES 
YES 
YES 

(3) 
128. 

YES 
YES 
YES 
YES 
YES 



YES 

NO 

NO 

YES 

NO 

NO 

NO 

YES 

NO 

NO 



YES 
YES 
DIALUP 
YES 
YES 
NO 
YES 
YES 
YES 
NO 



(1) 

(1) 

NO 

(1) 

(1) 

(1) 

NO 

(1) 

NO 

NO 



YES 

NO 

NO 

(2) 

YES 

NO 

NO 

YES 

NO 

NO 



YES 

LEN 

YES 

YES 

YES 

NO 

YES 

YES 

NO 

NO 



NO 

NO 

NO 

NO 

NO 

YES 

NO 

YES 

YES 

YES 



protocol activity transparently) 
544Mbps (USA) or 2. 048Mbps (W-Trade) 



OTHER CAPABILITIES: 














Application Processing 


YES 


YES 


NO 


NO 


NO 


NO 


Remote Line Concentration 


NO 


SOME 


NO 


A/A 


YES 


— - 


Session Pooling 


YES 


YES 


— 


NO 


NO 


— 


Implementation: 














Diskette Customization 


NO 


NO 


NO 


YES 


NO 


NO 


NCP Generation 


NO 


NO 


NO 


NO 


YES 


NO 


Program Installation 


YES 


YES 


YES 


NO 


YES 


YES 


Availability: 














Alternate Paths/Routes 


NO 


NO 


2-RBs 


YES 


YES 


NO 


TG Support 


NO 


NO 


2-RBs 


NO 


YES 


— 


Multiple Link Support 


NO 


NO 


2-RBs 


YES 


YES 


— 


Multiple T-R Support 


NO 


NO 


NO 


NO 


YES 


YES 


Integrated Redundancy/Avail 


NO 


NO 


NO 


NO 


YES 


NO 



Abbreviations: (T-R) Token-Ring 
(GW) Gateway (LM) LAN MANAGER 



(WS) Workstation 
(NV) NetView 



(RB) Remote Bridge 
(CA) Channel Adapter 
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READER'S COMMENT FORM 



TITLE 



IBM TOKEN-RING GATEWAYS AND BRIDGES -- 
COMPARISONS AND RECOMMENDATIONS FOR 
S/370 CONNECTIVITY 



FORM NUMBER 



ZZ78-0355-00 



NAME: 



TELEPHONE : 



OCCUPATION: 



COMMENTS : 



You may use this form to communicate your comments 
about this publication, its organization, or sub- 
ject matter, with the understanding that IBM may 
use or distribute whatever information you may 
supply in any way it believes appropriate without 
incurring any obligation to you. 



PLEASE MAIL TO: 



G. D. CRAIG 

INTERNATIONAL BUSINESS MACHINES CORPORATION 

TELECOMMUNICATIONS SYSTEMS SUPPORT 

DEPARTMENT 997/BUILDING 657 

P. 0. BOX 12195 

RESEARCH TRIANGLE PARK, NC 27709 
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